Kami baru-baru ini menerapkan patch yang disediakan vendor untuk OpenSSH. Patch ini menonaktifkan beberapa protokol pertukaran kunci dalam menanggapi serangan Logjam baru-baru ini. Setelah menerapkan tambalan ini, kami memiliki beberapa vendor yang kami belum dapat bertukar file melalui sftp karena negosiasi koneksi gagal (kemungkinan karena algoritma pertukaran kunci yang sudah tidak digunakan lagi).
Saya hanya ingin memverifikasi beberapa hal yang kami lihat sebelum berbicara dengan vendor kami. Berikut adalah contoh sesi SSH dengan salah satu vendor bermasalah (nomor baris ditambahkan):
# ssh -vv [email protected]
01 OpenSSH_6.2p2, OpenSSL 0.9.8j-fips 07 Jan 2009
02 debug1: Reading configuration data /etc/ssh/ssh_config
03 debug1: /etc/ssh/ssh_config line 20: Applying options for *
04 debug2: ssh_connect: needpriv 0
05 debug1: Connecting to host.domain.com [1.2.3.4] port 22.
06 debug1: Connection established.
07 debug1: permanently_set_uid: 0/0
08 debug1: identity file /root/.ssh/id_rsa type -1
09 debug1: identity file /root/.ssh/id_rsa-cert type -1
10 debug1: identity file /root/.ssh/id_dsa type -1
11 debug1: identity file /root/.ssh/id_dsa-cert type -1
12 debug1: identity file /root/.ssh/id_ecdsa type -1
13 debug1: identity file /root/.ssh/id_ecdsa-cert type -1
14 debug1: Enabling compatibility mode for protocol 2.0
15 debug1: Local version string SSH-2.0-OpenSSH_6.2
16 debug1: Remote protocol version 2.0, remote software version GXSSSHD_Comments
17 debug1: no match: GXSSSHD_Comments
18 debug2: fd 3 setting O_NONBLOCK
19 debug1: SSH2_MSG_KEXINIT sent
20 debug1: SSH2_MSG_KEXINIT received
21 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-group14-sha1,diffie-hellman-group1-sha1
22 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
23 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,[email protected]
24 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,[email protected]
25 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,[email protected],zlib
28 debug2: kex_parse_kexinit: none,[email protected],zlib
29 debug2: kex_parse_kexinit:
30 debug2: kex_parse_kexinit:
31 debug2: kex_parse_kexinit: first_kex_follows 0
32 debug2: kex_parse_kexinit: reserved 0
33 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256
34 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa
35 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
36 debug2: kex_parse_kexinit: aes128-cbc,3des-ctr,aes128-ctr,3des-cbc,blowfish-cbc,arcfour,arcfour128
37 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,[email protected]
39 debug2: kex_parse_kexinit: none,zlib
40 debug2: kex_parse_kexinit: none,zlib
41 debug2: kex_parse_kexinit:
42 debug2: kex_parse_kexinit:
43 debug2: kex_parse_kexinit: first_kex_follows 0
44 debug2: kex_parse_kexinit: reserved 0
45 debug2: mac_setup: found hmac-md5
46 debug1: kex: server->client aes128-ctr hmac-md5 none
47 debug2: mac_setup: found hmac-md5
48 debug1: kex: client->server aes128-ctr hmac-md5 none
49 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1536<3072<8192) sent
50 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
51 DH_GEX group out of range: 1536 !< 1024 !< 8192`
Jadi selama negosiasi pertukaran kunci, klien dan server bertukar daftar algoritma yang didukung (baris 21 dan 33). Mereka setuju untuk menggunakan kecocokan pertama yang ditemukan dalam dua daftar, dalam hal ini diffie-hellman-group-exchange-sha1. Seperti yang saya pahami, algoritma ini mendukung kisaran panjang bit yang harus dinegosiasikan oleh klien dan server. Dalam keadaan normal, klien dan server menyepakati sedikit panjang dan bertukar kunci menggunakan DH primer dari modulifile, misalnya /etc/ssh/moduli(saya tahu pernyataan terakhir ini sangat "orang awam berbicara," tapi itu kira-kira panjang dan pendeknya Itu).
Dalam hal ini, apa yang saya pikir saya lihat adalah bahwa negosiasi bit-length gagal. Pada baris 49, klien (saya) mengatakan "Saya mendukung panjang bit antara 1536 dan 8192 dan ingin menggunakan 3072 bit." Namun, server membalas dan berkata, "Saya hanya mendukung 1024 bit." Pada titik mana klien menyerah dan berkata, "Aku tidak bisa bicara denganmu." Apakah ini penjelasan yang masuk akal tentang apa yang terjadi di sini?
Seperti yang saya pahami, masalahnya sepenuhnya pada ujung server pada saat ini (dengan asumsi kita tidak menegosiasikan algoritma yang lebih lemah seperti diffie-hellman-group1-sha1). Server harus dimodifikasi untuk mendukung panjang bit yang lebih besar selama proses pertukaran kunci.
Saya ingin memastikan saya memahami ini dengan benar sebelum melanjutkan. Masukan dihargai.
sumber
Jawaban:
Jika Anda ingin menggunakan OpenSSH yang lebih baru untuk terhubung ke server yang sudah usang:
Tambahkan -v jika Anda ingin melihat apa yang terjadi, dan -o HostKeyAlgorithms = ssh-dss jika masih tidak berfungsi:
Anda juga dapat, tentu saja, mengedit / etc / ssh / ssh_config atau ~ / .ssh / ssh_config, dan menambahkan:
https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 menyebutkan perbaikan berikut pada Mikrotik Routerboards:
(Memperhatikan hal ini di sini karena jawaban ini juga muncul pada pencarian web ketika mencari pesan kesalahan yang serupa.)
Jika Anda ingin menggunakannya di atas Git tanpa mengedit ssh_config Anda atau memperbarui server SSH:
sumber
Tampaknya Anda telah menemukan bug ini .
...
Anda dapat menemukan 3 resolusi berbeda di tautan. Dalam situasi di mana Anda tidak memiliki kekuatan admin atau ada terlalu banyak birokrasi untuk mendapatkan perubahan yang lebih dalam, menyingkirkan algoritma yang bermasalah sambil menunggu ketersediaan SHA-2 di server sepertinya pilihan terbaik bagi saya. Anda bahkan dapat melakukannya dengan cara berbasis pengguna di file $ HOME / .ssh / config Anda.
sumber