SSH ke server NAT'd pada alamat IP publik yang sama

16

Saya mencoba SSH dari di kantor X ke beberapa kotak Linux di kantor Y. Kotak-kotak Linux di kantor Y ada di belakang NAT dan masing-masing dijalankan pada port mereka sendiri. Saya dapat berhasil menjangkau mereka semua melalui SSH, tetapi saya tidak dapat mengautentikasi.

Saya bisa memasukkan SSH ke dalam kotak pertama, tetapi ketika saya sampai di kotak kedua, tertulis:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
[edited out fingerprint]
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending key in /root/.ssh/known_hosts:1

Pemahaman saya adalah bahwa ia mengharapkan untuk melihat kunci yang sama dari alamat IP publik, tetapi melihat yang berbeda karena itu adalah server SSH yang berbeda.

Bagaimana saya bisa memperbaikinya sehingga membuat / menerima kunci yang berbeda dari setiap server di belakang alamat IP yang sama?

— Salin Jalankan Mulai
sumber

1

+1 untuk cloud yang digambar tangan.

— JoeG

15

Nama host atau alamat IP disimpan sebagai hash (atau dalam teks biasa tergantung pada opsi dan versi default) di known_hostsfile Anda . Solusi termudah adalah menambahkan entri untuk setiap host ke DNS atau /etc/hostsfile (ugh!) Dengan alamat IP (WAN) yang sama seperti di /etc/hosts:

your.wan.ip.address      servera serverb

dan kemudian sshdengan nama host dan port.

— Brandon Xavier
sumber

22

Ada beberapa cara untuk memperbaikinya:

Anda dapat menonaktifkan pemeriksaan kunci host untuk host khusus ini. Di ssh_configfile Anda ( ~/.ssh/config), masukkan sesuatu seperti:
```
Host remote.host.name
UserKnownHostsFile /dev/null
StrictHostkeyChecking no
```
Ini mengonfigurasikan sshuntuk tidak pernah menyimpan kunci host remote.host.name, tetapi downside adalah bahwa sekarang Anda terbuka untuk serangan man-in-the-middle (karena Anda secara buta menerima kunci host yang Anda tidak dapat mengetahui apakah kunci host jarak jauh telah berubah).
Anda dapat menggunakan teknik serupa untuk memberi masing-masing host known_hostsfile unik :
```
Host hosta
Port 10098
Hostname remote.host.name
UserKnownHostsFile ~/.ssh/known_hosts_hosta

Host hostb
Port 10099
Hostname remote.host.name
UserKnownHostsFile ~/.ssh/known_hosts_hostb
```
Anda kemudian akan terhubung ke host-host ini dengan ssh hostaatau ssh hostb, dan sshakan mengambil nama host dan port sebenarnya dari file konfigurasi.

— larsks
sumber

4

Tidak, memodifikasi /etc/hostsfile juga akan berfungsi. Saya suka ini lebih baik karena (a) tidak memerlukan hak akses yang meningkat dan (b) itu berarti Anda tidak perlu menentukan nomor port pada baris perintah.

— larsks

1

Resolusi nama (host atau DNS) masih akan diperlukan di kedua solusi ini untuk mengaitkan hosta dan hostb dengan alamat IP WAN. Tetapi keduanya adalah saran yang sangat baik saya terlalu malas untuk mengetik di LOL Edit: Baru saja perhatikan Hostname di sana - goresan itu tentang resolusi nama.

— Brandon Xavier

2

@CopyRunStart: Anda tidak perlu menentukan port pada baris perintah karena sudah ditentukan di ~/.ssh/config(port yang berbeda untuk masing-masing hosta hostb) seperti yang dijelaskan dalam jawaban larsks. Demikian juga Anda dapat menentukan nama pengguna, kunci, dll yang berbeda dalam file konfigurasi ini untuk host yang berbeda sehingga yang harus Anda lakukan pada baris perintah adalah ssh hostaataussh hostb

— arielf

3

Jika saya bisa meningkatkan / ~ .ssh / config dua kali, saya akan melakukannya. Mengotak-atik / etc / hosts terikat untuk menyebabkan masalah pemecahan masalah lainnya di jalan.

— Aaron

1

Ini adalah solusi yang jauh lebih baik, IMO, daripada memodifikasi / etc / hosts. Sebagai quibble minor, saya akan menggunakan HostKeyAliasarahan daripada membagi host yang dikenal ke file yang berbeda. misalnyaHostKeyAlias hosta

— crimson-egret

8

Anda tidak mengatakan versi Solaris mana (dan, yang lebih penting, SSH) yang Anda gunakan, tetapi versi OpenSSH yang mutakhir telah mengatasi masalah ini.

Berikut adalah dua entri dari known_hostsfile saya , yang memiliki alamat IP yang sama tetapi nomor port yang berbeda (satu adalah implisit 22); karena Anda dapat melihat kunci yang disimpan tidak sama.

[10.69.55.47]:2222 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAo+zenWwhFWAa/exdxbm3A3htDFGwFVjFlHLO83AfOaloBbBrr6whmLeDqVPBSwI/yrePClpahLUMYE6qGBFCbbOYiQkMDwacNFfxvxd6oCMDDqZH6NWGiBCt0b2M6YKYhYCw6z8n0yvlLk1eTdpp2OpjbfwAIe4eBkWyKNZY9+17VtzARqGR9tgHC8Dh7HBApDR8wooc+XzY6FhD2b21meIt8r8bjfBIu5t6eQgDHh/TzUT1rGH6W0HeUJxpDnpud5Af1ygMEQFrGrzHi5HKtg+K6HFBggMF8t6p2Dz8oMds5pi6IuPlVi3UvO1X7mMJ9pP7ByMQqiVrQ9wtAbC2QQ==
10.69.55.47 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA1clJ6vp8NDy7D9YVgAKQQzERfx3scR0c0027yOYGGpeLg+nW+x8mJk1ia9GouUTDME+NP2YDVZUEDog9rtTJvuLd22ZxfoC8LGboyBsmlhOVxdSCxmA/+blPCp1pyocr8pXyXjSkb/qQKKQMRoAU7qKKHPfI5Vugj04l6WbW2rJQTqFD/Lguc8AAUOE6K4DNhETOH2gOnwq6xi0vutDmeUKSqEvM/PQFZSlOL4dFDYO5jAUjvgm6yGHP3LlS9fmCzayJgGgLSnNz0nlcd94Pa1Cd441cCAZHFDvDPniawEafH9ok4Mmew0UGopQGUGbfb5+8g8YphLW6aLdrvnZbAw==

Saya tidak tahu versi OpenSSH mana yang memperkenalkan ini, tetapi saya sedang menjalankan

[me@risby fin]$ ssh -V
OpenSSH_6.9p1, OpenSSL 1.0.1k-fips 8 Jan 2015

— MadHatter
sumber

3

Untuk memperluas komentar saya ke jawaban @ larsks, saya pikir menggunakan ~/.ssh/configentri jauh lebih baik daripada memodifikasi / etc / hosts, meskipun saya akan menggunakan HostKeyAliasdaripada membagi host yang dikenal ke file yang berbeda. misalnya:

Host hosta
Port 10098
Hostname remote.host.name
HostKeyAlias hosta

Dan juga untuk hostb

— kuntul merah
sumber