SSH: gruppo DH_GEX fuori portata

18

Di recente abbiamo applicato una patch fornita dal fornitore per OpenSSH. Questa patch ha disabilitato alcuni protocolli di scambio di chiavi in ​​risposta al recente attacco Logjam. Dopo aver applicato questa patch, abbiamo alcuni fornitori con i quali non siamo stati in grado di scambiare file tramite sftp perché la negoziazione della connessione non riesce (probabilmente a causa degli algoritmi di scambio chiavi deprecati).

Vorrei solo verificare un paio di cose che stiamo vedendo prima di parlare con i nostri fornitori. Ecco una sessione SSH di esempio con uno dei fornitori problematici (numeri di riga aggiunti):

# ssh -vv user@host.domain.com
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: 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.com,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
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,rijndael-cbc@lysator.liu.se
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,rijndael-cbc@lysator.liu.se
25 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
26 debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
27 debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
28 debug2: kex_parse_kexinit: none,zlib@openssh.com,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,hmac-sha256@ssh.com
38 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-md5-96,hmac-sha1-96,hmac-sha256,hmac-sha256@ssh.com
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`

Pertanto, durante la negoziazione dello scambio di chiavi, il client e il server scambiano i loro elenchi di algoritmi supportati (righe 21 e 33). Accettano di utilizzare la prima corrispondenza trovata nelle due liste, in questo caso diffie-hellman-group-exchange-sha1. A quanto ho capito, questo algoritmo supporta una gamma di lunghezze di bit che il client e il server devono quindi negoziare. In circostanze normali, il client e il server concordano su un po 'di lunghezza e scambiano le chiavi facendo uso di un DH prime dal modulifile, ad esempio /etc/ssh/moduli(so che quest'ultima affermazione è molto "laica", ma che è all'incirca il lungo e il corto di esso).

In questo caso, ciò che penso di vedere è che la negoziazione a bitrate non riesce. Alla riga 49, il client (me) sta dicendo "Supporto lunghezze di bit comprese tra 1536 e 8192 e voglio utilizzare 3072 bit". Tuttavia, il server risponde e dice "Supporto solo 1024 bit". A quel punto il cliente si arrende e dice "Non posso parlarti". È una descrizione ragionevole di ciò che sta accadendo qui?

A quanto ho capito, il problema è interamente sul lato server a questo punto (supponendo che non negoziamo un algoritmo più debole come diffie-hellman-group1-sha1). Il server dovrebbe essere modificato per supportare lunghezze di bit maggiori durante il processo di scambio delle chiavi.

Vorrei assicurarmi di averlo compreso correttamente prima di procedere. L'input è apprezzato.

linux  ssh  linux-networking  sles 
— Sbrown
fonte
1
Lo stai leggendo bene. Cosa diavolo c'è all'altra estremità? Non sembra un server ssh comune.
— Michael Hampton
Non ho idea di quale sia il server. Stiamo riscontrando lo stesso problema con due diversi fornitori, entrambi banche. Nessuno dei due server si identifica nella sessione (il che non è sorprendente).
— sbrown
Penseresti che le banche sarebbero un po 'più in cima alla sicurezza, ma purtroppo ...
— Michael Hampton
2
La ricerca di "GXSSSHD_Comments" fa apparire commenti in vari forum client SFTP, che a loro volta sembrano suggerire che il tuo server sia l' applicazione GXS MFT - molto intraprendente.
— Castaglia,

Risposte:

21

Se si desidera utilizzare OpenSSH più recente per connettersi a server obsoleti:

ssh -o KexAlgorithms=diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-dss my.host.com

Aggiungi -v se vuoi vedere cosa sta succedendo e -o HostKeyAlgorithms = ssh-dss se continua a non funzionare:

ssh -v -o HostKeyAlgorithms=ssh-dss -o KexAlgorithms=diffie-hellman-group14-sha1 my.host.com

Puoi anche, ovviamente, modificare / etc / ssh / ssh_config o ~ / .ssh / ssh_config e aggiungere:

Host my.host.com *.myinsecure.net 192.168.1.* 192.168.2.*
    HostKeyAlgorithms ssh-dss
    KexAlgorithms diffie-hellman-group1-sha1

https://forum.ctwug.za.net/t/fyi-openssh-to-access-rbs-openssh-7/6069 menziona la seguente correzione sui router Mikrotik:

/ip ssh set strong-crypto=yes

(Notando questo qui perché questa risposta arriva anche nelle ricerche web quando si cerca un messaggio di errore simile.)

Se vuoi usarlo su Git senza modificare ssh_config o aggiornare il server SSH:

GIT_SSH="ssh -oHostKeyAlgorithms=+ssh-dss -oKexAlgorithms=diffie-hellman-group14-sha1" git clone ssh://user@host/path-to-repository
— Dagelf
fonte
2
questo funziona anche per sftp
— bao7uo,
11

Sembra che tu abbia colpito questo bug .

Causa

È stata apportata una modifica al pacchetto openssh, relativo allo scambio di gruppo Diffie-Hellman. In precedenza, si potevano scambiare chiavi di dimensioni 1024 - 8192. Il minimo è stato aumentato a 1536 per una maggiore sicurezza e per evitare la vulnerabilità "logjam". Tuttavia, se utilizzato con alcune implementazioni ssh di terze parti che supportano solo 1024, si verificherà un errore. Idealmente, la configurazione o il codice ssh di terze parti dovrebbe essere aggiornato per utilizzare chiavi di dimensioni maggiori.

...

Puoi trovare 3 diverse risoluzioni nel link. In situazioni in cui non hai il potere di amministratore o c'è troppa burocrazia per ottenere cambiamenti più profondi, sbarazzarsi dell'algoritmo problematico in attesa di una disponibilità SHA-2 nel server mi è sembrata l'opzione migliore. Puoi persino eseguirlo in modo basato sull'utente nel tuo file $ HOME / .ssh / config.

KexAlgorithms diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
— xmar
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.