Niedawno zastosowaliśmy łatę dostarczoną przez dostawcę dla OpenSSH. Ta łatka wyłączyła kilka protokołów wymiany kluczy w odpowiedzi na niedawny atak Logjam. Po zastosowaniu tej poprawki mamy kilku dostawców, z którymi nie byliśmy w stanie wymieniać plików przez sftp, ponieważ negocjacja połączenia kończy się niepowodzeniem (prawdopodobnie z powodu przestarzałych algorytmów wymiany kluczy).
Chciałbym tylko zweryfikować kilka rzeczy, które widzimy przed rozmową z naszymi dostawcami. Oto przykładowa sesja SSH z jednym z dostawców problemowych (dodano numery linii):
# 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`
Podczas negocjacji wymiany kluczy klient i serwer wymieniają się listami obsługiwanych algorytmów (wiersze 21 i 33). W tym przypadku zgadzają się użyć pierwszego dopasowania znalezionego na dwóch listach diffie-hellman-group-exchange-sha1. Jak rozumiem, ten algorytm obsługuje zakres długości bitów, które klient i serwer muszą następnie negocjować. W normalnych okolicznościach klient i serwer zgadzają się co do długości bitów i wymiany kluczy, wykorzystując liczbę pierwszą DH z modulipliku, np. /etc/ssh/moduli(Wiem, że to ostatnie zdanie jest bardzo „mówieniem laika”, ale z grubsza jest to długość to).
W tym przypadku wydaje mi się, że negocjacja długości bitów kończy się niepowodzeniem. W linii 49 klient (ja) mówi „Obsługuję długości bitów od 1536 do 8192 i chcę użyć 3072 bitów”. Jednak serwer odpowiada i mówi „Obsługuję tylko 1024 bity”. W tym momencie klient poddaje się i mówi „Nie mogę z tobą rozmawiać”. Czy to rozsądny opis tego, co się tutaj dzieje?
Jak rozumiem, w tym momencie problem leży całkowicie po stronie serwera (zakładając, że nie negocjujemy słabszego algorytmu, takiego jak diffie-hellman-group1-sha1). Serwer musiałby zostać zmodyfikowany, aby obsługiwał większe długości bitów podczas procesu wymiany kluczy.
Chciałbym się upewnić, że rozumiem to poprawnie przed kontynuowaniem. Doceniamy wkład.
źródło
Odpowiedzi:
Jeśli chcesz używać nowszej wersji OpenSSH do łączenia się z przestarzałymi serwerami:
Dodaj -v, jeśli chcesz zobaczyć, co się dzieje, i -o HostKeyAl algorytmy = ssh-dss, jeśli nadal nie działa:
Możesz również oczywiście edytować / etc / ssh / ssh_config lub ~ / .ssh / ssh_config i dodać:
https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 wspomina o następującej poprawce na routerach Mikrotik:
(Zwracając uwagę na to tutaj, ponieważ ta odpowiedź pojawia się również podczas wyszukiwania w Internecie, gdy szuka się podobnego komunikatu o błędzie).
Jeśli chcesz go używać przez Git bez edytowania ssh_config lub aktualizacji serwera SSH:
źródło
Wygląda na to, że trafiłeś w błąd .
...
W linku można znaleźć 3 różne rozdzielczości. W sytuacjach, w których nie masz uprawnień administratora lub jest zbyt duża biurokracja, aby uzyskać głębsze zmiany, pozbycie się problematycznego algorytmu podczas oczekiwania na dostępność SHA-2 na serwerze wydawało mi się najlepszą opcją. Możesz nawet wykonać go w sposób oparty na użytkownikach w pliku $ HOME / .ssh / config.
źródło