SSH berhenti bekerja setelah pembaruan server? Apa yang terjadi?

9

Saya telah menggunakan koneksi SSH berbasis PKI selama lebih dari 10 tahun. Tiba-tiba, setelah pembaruan server - beberapa koneksi berhenti berfungsi. Saya menggunakan kunci PKI yang sama yang telah saya gunakan selama bertahun-tahun (setiap server memiliki kunci sendiri, saya memiliki satu set kunci pribadi kecil).

Bekerja - terlihat seperti ini:

C:\Users\michael>ssh2 -p 2222 root@192.168.129.64 date
Authentication successful.
Fri Nov 25 10:30:42  2016

Tidak berfungsi seperti:

C:\Users\michael>ssh2 root@192.168.129.64 date
warning: Authentication failed.
Disconnected; key exchange or algorithm negotiation failed (Algorithm negotiation failed.).

Apa yang berubah?

openssh 
— Michael Felt
sumber
2
Setiap kali saya memutakhirkan atau mengkonfigurasi ulang SSH, saya biasanya segera mencoba membuka koneksi SSH lainnya sementara membiarkan koneksi saat ini terbuka untuk debugging. Pendekatan itu akan membantu debugging dalam skenario seperti milik Anda. Apakah Anda masih memiliki akses ke server? Atau Anda mencoba men-debug ini dari sisi klien tanpa akses untuk melihat log sisi server sampai Anda menyelesaikan masalah?
— kasperd
1
Saya selalu punya akses ke server, untungnya. Secara umum, ketika menerapkan pembaruan saya mencoba untuk menjadi 'di konsol' - untuk alasan seperti yang Anda sebutkan. Apa yang saya coba tunjukkan di sini adalah bagaimana men-debug ketika itu bekerja untuk beberapa (misalnya, dempul baru-baru ini), tetapi tidak yang lain (misalnya, ssh-client berusia 14 tahun yang tidak tahu peningkatan algoritma cipher, kex, dan mac.
— Michael Felt

Jawaban:

14

Setelah pembaruan - efek samping mungkin ikut berperan. Dengan OpenSSH - standar sering berubah. OpenBSD (yang memelihara / mengembangkan OpenSSH) memiliki kebijakan OpenBSD untuk tidak khawatir tentang kompatibilitas ke belakang. Ini bisa 'mematahkan' hal-hal yang, baca dulu, bekerja dengan baik.

Ada petunjuk besar - bahwa saya tidak melihat ketika ini pertama kali terjadi pada saya (menggunakan antarmuka GUI, dan saya hanya mengkliknya dan 'marah' dengan 'pembaruan bodoh - versi baru rusak'. Ternyata versi baru tidak rusak - tetapi OpenBSD / OpenSSH mulai mengubah default pertukaran kunci yang dimulai dengan OpenSSH-6.7p1 lihat: http://www.openssh.com/txt/release-6.7 , khususnya:

Perubahan sejak OpenSSH 6.6

Perubahan yang berpotensi tidak kompatibel

  • sshd (8): Perangkat cipher dan MAC default telah diubah untuk
    menghapus algoritma yang tidak aman. Khususnya, sandi CBC dan arcfour *
    dinonaktifkan secara default.

    Set lengkap algoritma tetap tersedia jika dikonfigurasi
    secara eksplisit melalui opsi sshd_config Cipers dan MAC.

Masalah saya adalah saya memiliki klien lama yang tidak memiliki default baru, sehingga tidak dapat terhubung.

Dua jalur solusi: memperbaiki / menambal server atau - memperbaiki / menambal klien.

Solusi server: kembalikan pengaturan "lama" agar klien "lama" dapat terus terhubung, - ramah kepada klien yang ada - mengedit file sshd_config dan menambahkan kembali (cukup) dari sandi lama.

Baris kunci untuk mengubah / menambahkan sshd_config adalah:

ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc
KexAlgorithms  curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

Cukup tambahkan:

# Ciphers
# The dafaults starting with OpenSSH 6.7 are:
# aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com
# older clients may need an older cipher, e.g.
# ciphers aes128-cbc,aes192-cbc,aes256-cbc,blowfish-cbc,arcfour
# only adding aes256-cbc as an "old" cipher

ciphers aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305@openssh.com,aes256-cbc

# KEX Key Exchange algorithms
# default from openssh 6.7 are:
# curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,\
#  diffie-hellman-group14-sha1
# an older kex are: none,KexAlgorithms diffie-hellman-group1-sha1

# only adding diffie-hellman-group-sha1  as an "old" KEX
# and this should be deleted ASAP as it is clearly "one of the problems" with SSL based encryption
KexAlgorithms  curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

# MAC message authentification code
# the new defaults are:
# umac-64-etm@openssh.com,umac-128-etm@openssh.com,
# hmac-sha2-256-etm@openssh.com,hmac-sha2-512-
# etm@openssh.com,
# umac-64@openssh.com,umac-128@openssh.com,
# hmac-sha2-256,hmac-sha2-512

# older defaults (still supported) are:
# macs hmac-sha1,hmac-md5

# consider removing hmac-sha1-96,hmac-sha1,hmac-md5 "Soon!"
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

Solusi # 2 - memperbaiki / mengganti klien

Cara mudah untuk melihat cipher apa yang Anda dukung klien saat ini (dengan asumsi CLI) ssh -hdan lihat apakah itu menyediakan sesuatu seperti:

Supported ciphers:
  3des-cbc,aes256-cbc,aes192-cbc,aes128-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,des-cbc@ssh.com,cast128-cbc,rc2-cbc@ssh.com,arcfour,none
Supported MAC algorithms:
  hmac-md5,hmac-md5-96,hmac-sha1,hmac-sha1-96,hmac-sha256@ssh.com,hmac-sha256-96@ssh.com,hmac-ripemd160@ssh.com,hmac-ripemd160-96@ssh.com,hmac-tiger128@ssh.com,hmac-tiger128-96@ssh.com,hmac-tiger160@ssh.com,hmac-tiger160-96@ssh.com,hmac-tiger192@ssh.com,hmac-tiger192-96@ssh.com,none

Perintah lain yang bermanfaat adalah: ssh -V

ssh2: SSH Secure Shell 3.2.9 Windows Client
Product: SSH Secure Shell for Workstations
License type: none (non-commercial)

Milik saya - adalah - klien yang sangat lama - untuk desktop saya. Melihat di atas Anda dapat melihatnya tidak mendukung salah satu dari - 15 tahun kemudian - algoritma yang disukai, bahkan tidak satu-cbr (berputar), hanya -cbc (blok-copy).

Jika klien Anda tidak memiliki opsi untuk menyediakan kunci, dll. Yang didukung (OpenSSH seharusnya memiliki opsi -Q) mulai saja koneksi ke diri Anda sendiri, mis., ssh -v localhostDan ada garis-garis seperti ini untuk memberi tahu Anda apa yang diketahui:

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-grousha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysatiu.se
...

Dan apa yang ditemukan (dan digunakan):

debug2: mac_setup: found hmac-sha1
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug2: mac_setup: found hmac-sha1
debug1: kex: client->server aes128-ctr hmac-sha1 none

Ekstra: info debug dari koneksi yang gagal - detail lebih lanjut

Atau, apa yang sudah dicoba, tetapi luput.

debug: OpenSSH: Major: 7 Minor: 3 Revision: 0
debug: Ssh2Transport: All versions of OpenSSH handle kex guesses incorrectly.
debug: Ssh2Transport: Algorithm negotiation failed for c_to_s_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug: Ssh2Transport: Algorithm negotiation failed for s_to_c_cipher: client list: aes128-cbc,3des-cbc,twofish128-cbc,cast128-cbc,twofish-cbc,blowfish-cbc,aes192-cbc,aes256-cbc,twofish192-cbc,twofish256-cbc,arcfour vs. server list : chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug: Ssh2Transport: lang s to c: `', lang c to s: `'
debug: Ssh2Transport: Couldn't agree on kex or hostkey alg. (chosen_kex = NULL, chosen_host_key = ssh-rsa)
debug: Ssh2Common: DISCONNECT received: Algorithm negotiation failed.

Sunting: ditambahkan 02-Januari-2017

Bagian Baru - bagaimana dengan kunci yang berhenti berfungsi?

Di server saya, saya memiliki klien 'lama' dan klien 'terbaru' terinstal - dan mendapatkan perilaku berbeda yang terhubung ke server. Di sini masalahnya bukan ketidakcocokan cipher - tetapi penggunaan pasangan PKI kuno - berdasarkan DSA.

Singkatnya, openssh-7 (.3) tidak lagi mengirim (secara default, mungkin tidak sama sekali) kunci publik DSA.

Di bawah ini saya membandingkan output dari dua versi openssh
/ usr / bin / ssh (versi lama, sisi kiri) dan
/ opt / bin / ssh (versi baru, sisi kanan) - perintahnya adalah:

${version}/ssh -v user@host date

Saat Anda memindai melalui output di bawah ini, saya harap Anda memperhatikan langkah-langkah dan pesan-pesan pada umumnya sama. Perbedaan utama muncul setelah string SSH2_MSG_SERVICE_ACCEPT

Yang saya ingin Anda perhatikan adalah bahwa versi lama menawarkan (dan diterima oleh server 'lama' - pasangan kunci berbasis DSA sementara server baru tidak pernah menawarkan kunci berbasis DSA.

Catatan: 'solusi' untuk ini adalah menambahkan (setidaknya satu dari) pasangan rsa, ecdsa, atau pasangan PKI berbasis ed25519.

OpenSSH_6.0p1, OpenSSL 1.0.2h  3 May 2016                     | OpenSSH_7.3p1, OpenSSL 1.0.2h  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config        | debug1: Reading configuration data /var/openssh/etc/ssh_confi
debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): <
        0509-026 System error: A file or directory in the pat <
                                                              <
debug1: Error loading Kerberos, disabling Kerberos auth.      <
debug1: Connecting to x061 [192.168.129.61] port 22.            debug1: Connecting to x061 [192.168.129.61] port 22.
debug1: Connection established.                                 debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1          debug1: identity file /home/michael/.ssh/id_rsa type 1
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1    debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type 2          debug1: identity file /home/michael/.ssh/id_dsa type 2
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1    debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: identity file /home/michael/.ssh/id_ecdsa type 3        debug1: identity file /home/michael/.ssh/id_ecdsa type 3
                                                              > debug1: key_load_public: No such file or directory
debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -   debug1: identity file /home/michael/.ssh/id_ecdsa-cert type -
debug1: Remote protocol version 2.0, remote software version  | debug1: key_load_public: No such file or directory
debug1: match: OpenSSH_6.0 pat OpenSSH*                       | debug1: identity file /home/michael/.ssh/id_ed25519 type -1
                                                              > debug1: key_load_public: No such file or directory
                                                              > debug1: identity file /home/michael/.ssh/id_ed25519-cert type
debug1: Enabling compatibility mode for protocol 2.0            debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0              | debug1: Local version string SSH-2.0-OpenSSH_7.3
                                                              > debug1: Remote protocol version 2.0, remote software version
                                                              > debug1: match: OpenSSH_6.0 pat OpenSSH* compat 0x04000000
                                                              > debug1: Authenticating to x061:22 as 'padmin'
debug1: SSH2_MSG_KEXINIT sent                                   debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received                               debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none          | debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: client->server aes128-ctr hmac-md5 none          | debug1: kex: host key algorithm: ssh-rsa
                                                              > debug1: kex: server->client cipher: aes128-ctr MAC: umac-64@o
                                                              > debug1: kex: client->server cipher: aes128-ctr MAC: umac-64@o
debug1: sending SSH2_MSG_KEX_ECDH_INIT                          debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY                       debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 9f:0a:4d:a8:1b:ba:e6:d4:1a:b2:cd | debug1: Server host key: ssh-rsa SHA256:ORf5UVI7mRm/9MthM2qXM
debug1: Host 'x061' is known and matches the RSA host key.      debug1: Host 'x061' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:57          debug1: Found key in /home/michael/.ssh/known_hosts:57
debug1: ssh_rsa_verify: signature correct                     | debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent                                   debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS                              debug1: expecting SSH2_MSG_NEWKEYS
                                                              > debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS received                               debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server                         | debug1: Skipping ssh-dss key /home/michael/.ssh/id_dsa - not
debug1: SSH2_MSG_SERVICE_REQUEST sent                         <
debug1: SSH2_MSG_SERVICE_ACCEPT received                        debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey                   debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/michael/.ssh/id_rsa      debug1: Offering RSA public key: /home/michael/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password   debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: /home/michael/.ssh/id_dsa    | debug1: Offering ECDSA public key: /home/michael/.ssh/id_ecds
debug1: Server accepts key: pkalg ssh-dss blen 433            | debug1: Authentications that can continue: publickey,password
debug1: read PEM private key done: type DSA                   | debug1: Trying private key: /home/michael/.ssh/id_ed25519
debug1: Authentication succeeded (publickey).                 | debug1: Next authentication method: keyboard-interactive
Authenticated to x061 ([192.168.129.61]:22).                  | debug1: Authentications that can continue: publickey,password
debug1: channel 0: new [client-session]                       | debug1: Next authentication method: password
debug1: Requesting no-more-sessions@openssh.com               | padmin@x061's password:
debug1: Entering interactive session.                         |
— Michael Felt
sumber
Saya juga punya pengguna di sini mengeluh tentang kunci dengan protokol usang pada saat saya upgrade ke Debian 8.
— Rui F Ribeiro
1
Saya lupa menyebutkan - bahwa untuk windows saya, saya beralih ke dempul (ssh.com hanya menjual ke bisnis) - akan tetap bertahan ssh2jika mereka mau menerima saya - terutama untuk kemudahan melakukan scptransfer dari jendela yang sama denganssh
— Michael Felt
1
Perbarui klien Anda alih-alih menggunakan klien lama dan aktifkan kemungkinan algoritma yang rusak.
— Jakuje
1
Lihat Meningkatkan kunci SSH Anda! untuk detail lebih lanjut, tetapi seperti yang dikatakan @Jujuje, adalah ide yang buruk untuk menyimpan kunci lama, klien lama dan algoritma lama.
— Stephen Kitt
usia kunci bukan masalah, imho - tetapi jenis dan ukurannya. "DSA" keluar, "RSA" setidaknya 2048-bit. 'Lebih baik' adalah ecdsa. Seperti @Jakuje menyebutkan - dan apa T&J ini - memperbarui klien - tetapi juga memperbarui default. Sebagai klien Anda dapat 'menuntut' server menggunakan algoritma yang lebih baik dengan tidak menawarkan yang lemah (rusak lebih buruk).
— Michael Felt
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.