Akses SSH ke host kantor di belakang router NAT


33

Saya ingin mengakses port ssh host linux kantor saya dari rumah. Sayangnya tuan rumah terletak di belakang router NAT. Jadi, alamat IP tidak tersedia untuk umum. Namun ada akses ke host internet lain (Server) yang sayangnya hanya akses non-root. Setelah beberapa saat mencari saya tidak menemukan solusi yang cocok.

Pengaturan berikut:

  • Office PC (linux, akses root) di belakang NAT (IP bukan publik) tetapi akses Internet penuh.
  • Server PC (linux, tanpa akses root) IP statis dan publik dan akses Internet penuh.
  • PC rumah (linux, akses root) di belakang NAT (IP bukan publik) tetapi akses Internet penuh.

Kemungkinan koneksi: Office PC -> Server <- Home PC

Tidak mungkin: PC Kantor <-X- Server -X-> PC Rumah

Baik PC Rumah, maupun Server dapat memulai akses ke PC Office. Tetapi Office PC dan Home PC dapat memulai koneksi ke Server.

Membalikkan SSH tunnel tidak mungkin: Saya mencoba metode yang disebut reverse ssh-tunnel. Sayangnya ini membutuhkan GatewayPorts di Server diatur ke "ya" di / etc / ssh / sshd_config, di mana saya tidak memiliki akses root.

Pada prinsipnya itu harus dimungkinkan:

0) Di Server saya memulai program userspace yang mendengarkan pada 2 port (1 masuk, 1 keluar)

1) Di PC kantor saya, saya menjalankan program lain yang membuat koneksi TCP terbuka ke port keluar di server.

2) Dari rumah saya terhubung ke port masuk Server.

Seharusnya ada solusi standar untuk ini di luar sana.

Apa solusi tercepat dan terbersih untuk menyelesaikan ini?

jujur


1
dapatkah PC kantor terhubung ke rumah menyiapkan terowongan ssh? en.gentoo-wiki.com/wiki/Autossh

Anda dapat menggunakan FileZilla dengan sftp dan port forwarding. Lihat: superuser.com/a/1286681/141314
Noam Manos

Jawaban:


31
youatwork@officepc$ autossh -R 12345:localhost:22 notroot@serverpc

Kemudian:

you@homepc$ autossh -L 23456:localhost:12345 notroot@serverpc

you@homepc$ ssh youatwork@localhost -p 23456

Apa yang dapat Anda lakukan adalah ini: pada langkah 1 meneruskan port jarak jauh dari PC kantor ke server ( 12345digunakan sebagai contoh, port apa pun> 1024 yang harus dilakukan). Sekarang terhubung ke 12345 di server akan menghubungkan Anda ke port 22 di officepc.

Pada langkah 2, teruskan port 23456 dari mesin di rumah Anda ke 12345 di server (saat itu diteruskan ke officepc: 22, sebagaimana diatur dalam langkah 1)

Pada langkah 3, Anda terhubung ke port lokal 23456 dengan login PC kantor Anda . Ini diteruskan oleh langkah 2 ke port 12345 di server Anda, dan dengan langkah 1 ke PC kantor Anda.

Perhatikan bahwa saya menggunakan autossh untuk penerusan, karena ini adalah pembungkus ssh yang secara otomatis menghubungkan kembali terowongan jika harus diputus; Namun ssh normal akan berfungsi juga, selama koneksi tidak turun.

Ada kemungkinan kerentanan: siapa pun yang dapat terhubung ke localhost: 12345 di serverpc sekarang dapat terhubung ke officepc: 22, dan mencoba untuk meretas ke dalamnya. (Perhatikan bahwa jika Anda menjalankan server SSH, Anda harus tetap mengamankannya di atas perlindungan dasar yang aktif secara default; Saya sarankan setidaknya menonaktifkan login root dan menonaktifkan otentikasi kata sandi - lihat misalnya ini )

Sunting : Saya telah memverifikasi ini dengan konfigurasi yang sama, dan berfungsi. GatewayPorts nohanya memengaruhi porta yang terbuka untuk dunia pada umumnya, bukan terowongan lokal. Inilah port yang diteruskan:

homepc:
  outgoing ssh to serverpc:22
  listening localhost:23456 forwarded through ssh tunnel
serverpc:
  listening ssh at *:22
  incoming localhost ssh tunnel (from homepc) forwarded to localhost:12345
  listening localhost ssh tunnel (from officepc) forwarded from localhost:12345
officepc:
  outgoing ssh to serverpc:22
  incoming localhost through ssh tunnel (from serverpc) forwarded to localhost:22

Jadi, sejauh menyangkut tumpukan jaringan, itu semua lalu lintas lokal pada antarmuka loopback masing-masing (ditambah koneksi ssh ke serverpc); oleh karena itu, GatewayPortstidak dicentang sama sekali.

Akan tetapi, ada arahannya AllowTcpForwarding: jika demikian no, pengaturan ini akan gagal karena tidak ada penerusan yang diizinkan sama sekali, bahkan tidak melintasi antarmuka loopback.

Peringatan :

  • Jika menggunakan autossh dan ssh terbaru, Anda mungkin ingin menggunakan ssh ServerAliveIntervaldan ServerAliveCountMaxuntuk menjaga terowongan. Autossh memiliki cek bawaan, tetapi ternyata ada beberapa masalah pada Fedora. -M0menonaktifkannya, dan -oServerAliveInterval=20 -oServerAliveCountMax=3memeriksa apakah koneksi sudah aktif - mencoba setiap 20 detik, jika gagal 3x berturut-turut, berhenti ssh (dan autossh membuat yang baru):

    autossh -M0 -R 12345:localhost:22 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
    
    autossh -M0 -L 23456:localhost:12345 -oServerAliveInterval=20 -oServerAliveCountMax=3 notroot@serverpc
    
  • mungkin berguna untuk memulai kembali ssh tunnel jika penerusan gagal, menggunakan -oExitOnForwardFailure=yes- jika port sudah terikat, Anda mungkin mendapatkan koneksi SSH yang berfungsi, tetapi tidak ada penerusan terowongan.

  • ~/.ssh/configdisarankan menggunakan opsi (dan port), jika tidak, baris perintah terlalu bertele-tele. Sebagai contoh:

    Host fwdserverpc
        Hostname serverpc
        User notroot
        ServerAliveInterval 20
        ServerAliveCountMax 3
        ExitOnForwardFailure yes
        LocalForward 23456 localhost:12345
    

Kemudian Anda dapat menggunakan hanya alias server:

    autossh -M0 fwdserverpc

Saya percaya metode yang Anda duga ini disebut "reverse ssh-tunnel". Sayangnya ini membutuhkan GatewayPorts di Server diatur ke "ya" di / etc / ssh / sshd_config. Server ini tidak memiliki port gateway yang memungkinkan dan saya tidak memiliki akses root di sana.

3
@ Frank: Sebenarnya, saya tidak berpikir begitu: GatewayPorts nomembatasi port yang dibuka hanya dapat diakses pada antarmuka loopback; perhatikan bahwa pada langkah 2 Anda meneruskan pada antarmuka loopback (pada kenyataannya, kedua ke depan adalah "hanya localhost"), jadi ini mungkin bekerja ( AllowTcpForwarding nodalam sshd config akan memecahkan ini).
Piskvor

3
@ Jujur: Yup, dikonfirmasi. Ini bekerja bahkan dengan GatewayPorts no; edit jawabannya. Perhatikan bahwa ada arahan lain (seperti PermitOpendan AllowTcpForwarding) yang dapat merusak pengaturan ini: manpagez.com/man/5/sshd_config
Piskvor

1
Jawaban yang sangat bagus! Berhasil, Anda menyelamatkan akhir pekan saya! Terimakasih banyak!!

1
versi autossh saya (Fedora Core) tidak dapat berjalan dari terminal tanpa -M. Saya juga terhubung dengan orang lain yang mengalaminya. Anda benar bahwa dalam manual itu ditandai sebagai argumen opsional. Bagus jika itu bekerja untuk banyak orang, disayangkan tidak untuk semua.
Yaroslav Nikitenko

4

Jika Anda dapat ssh ke server internal dari rumah dan dari server internal ke mesin Linux kantor Anda, maka dari rumah Anda dapat menggunakan ssh ProxyCommanduntuk memantul secara diam-diam melalui server ke mesin internal melalui nc(netcat)

# ~/.ssh/config on your home machine:
Host internalpc 
   ForwardAgent yes 
   ProxyCommand ssh user@server.example.com exec nc internal.pc.example.com %p

Kemudian Anda hanya ssh user@internalpcdan Anda diam-diam diteruskan melalui mesin server, tidak ada pembukaan port atau terowongan yang diperlukan di kedua ujung.


1
Terima kasih atas jawaban anda. Sayangnya, baik PC Rumah, maupun Server tidak dapat memulai akses ke PC Office. Tetapi Office PC dan Home PC dapat memulai koneksi ke Server.

4

Instal Robo-TiTO di komputer yang ingin Anda akses SSH dari jarak jauh.

  • Ini akan memungkinkan Anda untuk mengakses SSH menggunakan dari Aplikasi Google Talk Client di mana saja.
  • Tidak perlu untuk alamat IP publik atau pengaturan khusus.
  • Ini Gratis dan Sumber Terbuka, Tidak Membayar layanan aplikasi apa pun lagi.
  • Tidak perlu membuka port SSH (jaga keamanan komputer Anda).
  • Tidak perlu membuka tunneling (mis., VPN atau semacamnya)

Petunjuk penginstalan berikut sudah usang, karena situs telah dipindahkan. URL baru adalah https://github.com/formigarafa/robotito

Saya membuat skrip (diuji pada OS Raspbian saya di Raspberry Pi) sehingga Anda dapat dengan mudah menginstal Robo-TiTO pada Raspberry Pi, Debian atau Ubuntu Box (distribusi paket Debian). ini adalah langkah-langkah untuk membuat kotak Linux Anda dapat di-remoteable:

  1. Buka Shell Command atau Anda bisa menyebutnya Terminal, buka folder rumah Anda, Unduh skrip penginstal dengan perintah:

    $ wget https://opengateway.googlecode.com/files/robotito
    
  2. setelah itu jalankan skrip dengan memasukkan perintah:

    $ sudo ./robotito
    
  3. dan kemudian Anda dapat mengedit file credentials.rbdari folder konfigurasi Robo-TiTO menggunakan akun GTalk Anda dan menyimpannya dengan menekan Ctrl+ Xdan Y. Default menggunakan editor nano.

  4. menjalankan Robo-TiTO dari folder Robo-TiTO dengan perintah

    $ cd robotito
    $ ./jabbershd start
    
  5. Sekarang setelah selesai, Anda dapat menggunakan SSH dari klien bicara Google mana pun. Jangan lupa untuk menambahkan akun Robo-TiTO GTalk ke akun Google talk Anda dan mengujinya dengan saling mengobrol sebelum menggunakan akun tersebut.


5
Saya memiliki masalah serius dengan "Tidak perlu membuka port SSH (simpan komputer Anda menyimpan )" - bot shell-over-jabber yang Anda usulkan dijamin dengan, quote CLIENT_PASSPHRASE = "logmein",, dalam plaintext . Itu benar-benar nol keamanan - Anda membuat lubang seukuran truk untuk siapa pun untuk masuk. Kontras dengan otentikasi kunci publik SSH: Saya mengautentikasi melalui saluran aman , menggunakan kredensial yang bahkan tidak pernah terlintas. Siapa yang menjaga keamanan komputer mereka sekarang?
Piskvor

@Piskvor, robotito hanya akan menjalankan perintah dari kontak yang masuk daftar putih. github.com/formigarafa/robotito/blob/master/config/…
formigarafa

Saya tidak pernah mengalami masalah karena otentikasi berbasis daftar putih. Jika saya tidak salah, transfer pesan dienkripsi saat menggunakan dengan GTalk. Dengan satu atau lain cara, saya mengubahnya baru-baru ini dan sekarang menggunakan Kata Sandi Satu Kali dari alat seperti Google Authenticator atau yang serupa untuk memungkinkan akses.
formigarafa

1
@formigarafa: (1) Jika Anda atau telah terlibat dalam pengembangan produk ini, Anda harus mengatakannya secara eksplisit. Menggunakan nama yang sama tidak cukup; kebanyakan orang tidak akan memperhatikan itu. (Anda dapat menyebutkannya di profil Anda .) (2) Ketika Anda mengedit posting, Anda harus memperbaikinya sebanyak mungkin. Misalnya, cobalah menangkap kesalahan ketik seperti "I'ts". Dan, jika sebuah tautan telah rusak, jangan hanya menandainya sebagai tautan mati; masukkan URL baru ke dalam postingan . Orang tidak harus menggali komentar untuk menemukan informasi yang benar.
G-Man Mengatakan 'Reinstate Monica'

@ G-Man, Jawaban dan edit asli bukan milikku. Dan saya tidak pernah memiliki niat untuk membuatnya terlihat seperti milik saya. Saya perhatikan ada tautan mati pada jawabannya, saya juga tidak membuat tautan. Saya sebenarnya tertarik untuk melihat isinya dan mencoba mengikutinya. Sayangnya saya tidak dapat menemukan sumbernya. Saya menandai sebagai tautan mati dengan harapan bahwa siapa pun yang menulis jawaban akan diberitahu oleh perubahan dan mencoba memperbaikinya.
formigarafa

3

Solusi Piskvor bekerja dan bagus. Namun, itu membuat terminal menggantung terbuka dengan shell login menggantung. Tidak terlalu keren.

Saya selalu menggunakan skrip kecil ini yang saya tulis untuk terhubung ke server dan tetap terhubung dengan menjalankannya di cron:

#!/bin/bash
TARGET_HOST=${1:-myserver.example.com}
TARGET_PORT=${2:-7777}
TUNNEL_PORT=${3:-22}
T_USER="odin"

#Check that we have an active connection to the remote system
ACTIVE_PROCESS=`ps -ef | \
    grep "ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT" | \
    grep -v grep | \
    wc -l`
if [ $ACTIVE_PROCESS -lt 1 ]; then
    echo "`date` : establishing connection to $TARGET_HOST on port $TARGET_PORT"
    screen -m -d ssh $TARGET_HOST -l $T_USER -R $TARGET_PORT:127.0.0.1:$TUNNEL_PORT > /dev/null
fi

Saya yakin kita bisa memperbaiki solusi Piskvor menggunakan autossh yang lebih elegan di samping mungkin layar terpisah atau menggunakan argumen -NT ssh untuk hanya menjaga koneksi di latar belakang.


Terima kasih atas pujiannya :) Untuk kasus penggunaan saya, saya secara teratur membutuhkan akses shell, serta penerusannya; ditambah, saya telah mencoba untuk menunjukkan kasus minimal di sini (dimungkinkan untuk menyederhanakan hal di atas menjadi dua perintah dengan host hopping SSH transparan, tetapi itu akan memerlukan konfigurasi tambahan pada homepckomputer).
Piskvor

2

Bagi saya, kedengarannya seperti, alih-alih terowongan SSH, Anda harus mencoba VPN: jenis yang berfungsi dengan menggunakan server di luar untuk proxy melalui, seperti Hamachi . Ada software gratis lainnya seperti ini, tetapi Hamachi adalah favorit saya.


1
Sekarang karena 5.0.0.0/8jaringan benar-benar memiliki alamat IPv4 publik yang ditetapkan, Hamachi dalam masalah (jika Hamachi sedang berjalan, Anda tidak dapat mengakses bagian internet yang agak acak). Juga, Hamachi tidak lagi bebas digunakan.
Piskvor
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.