SSH ha smesso di funzionare dopo un aggiornamento del server? Quello che è successo?


9

Uso connessioni SSH basate su PKI da oltre 10 anni. All'improvviso, dopo un aggiornamento del server, alcune connessioni hanno smesso di funzionare. Sto usando le stesse chiavi PKI che ho usato per anni (ogni server ha le sue chiavi, ho un piccolo set di chiavi personali).

Funzionante: assomiglia a questo:

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

Non funziona sembra:

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

Che cosa è cambiato?


2
Ogni volta che aggiorno o riconfiguro SSH generalmente cerco immediatamente di aprire un'altra connessione SSH lasciando aperta la connessione corrente per il debug. Tale approccio aiuterebbe con il debug in scenari come il tuo. Hai ancora accesso al server? Oppure stai provando a eseguire il debug dal lato client senza accesso per guardare i registri lato server fino a quando non hai risolto il problema?
Kasperd,

1
Per fortuna ho sempre avuto accesso al server. In generale, quando applico gli aggiornamenti cerco di essere "sulla console" - per motivi come hai menzionato. Quello che ho cercato di mostrare qui è come eseguire il debug quando funziona per alcuni (ad esempio, stucco recente), ma non per altri (ad esempio, ssh-client di 14 anni che non conosce algoritmi di cifratura, kex e mac migliorati
Michael Felt

Risposte:


14

Dopo un aggiornamento, possono entrare in gioco effetti collaterali. Con OpenSSH - le impostazioni predefinite cambiano frequentemente. OpenBSD (che mantiene / sviluppa OpenSSH) ha una politica di OpenBSD per non preoccuparsi della retrocompatibilità. Questo può "spezzare" le cose che, si legge, funzionavano bene.

C'è un enorme suggerimento - che non ho notato quando mi è successo per la prima volta (usando l'interfaccia della GUI, e l'ho semplicemente cliccato e 'ero arrabbiato' con 'stupido aggiornamento - la nuova versione è rotta'. Viene fuori la nuova versione non è stato interrotto - ma OpenBSD / OpenSSH ha iniziato a modificare le impostazioni predefinite dello scambio di chiavi a partire da OpenSSH-6.7p1, consultare: http://www.openssh.com/txt/release-6.7 , in particolare:

Modifiche rispetto a OpenSSH 6.6

Modifiche potenzialmente incompatibili

  • sshd (8): il set predefinito di cifre e MAC è stato modificato per
    rimuovere algoritmi non sicuri. In particolare, i codici CBC e arcfour *
    sono disabilitati per impostazione predefinita.

    Il set completo di algoritmi rimane disponibile se configurato
    esplicitamente tramite le opzioni sshd_config di Cipher e MAC.

Il mio problema è che ho un vecchio client che non ha nessuno dei nuovi valori predefiniti, quindi non può connettersi.

Due percorsi di soluzione: correzione / patch del server o - correzione / patch del client.

Soluzione server: ripristina le impostazioni "vecchie" in modo che i client "vecchi" possano continuare a connettersi, vale a dire - amichevole per i client esistenti - modifica il file sshd_config e aggiungi (abbastanza) le vecchie cifre.

Le linee chiave da modificare / aggiungere in sshd_config sono:

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

Aggiungi solo:

# 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

Soluzione n. 2: correggere / sostituire il client

Un modo semplice per vedere quali cifre sono supportate dal client corrente (presupponendo CLI) ssh -he vedere se ciò fornisce qualcosa di simile:

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

Un altro comando utile è: ssh -V

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

Il mio - era - un client molto vecchio - per il mio desktop. Guardando sopra puoi vedere che non supporta nessuno degli algoritmi - 15 anni dopo - preferiti, nemmeno uno -cbr (rotante), solo -cbc (block-copy).

Se il tuo client non ha un'opzione per fornire le chiavi, ecc. Supportato (OpenSSH dovrebbe avere l'opzione -Q) basta avviare una connessione a te stesso, ad esempio, ssh -v localhoste ci sono linee come questa per dirti che wat è noto:

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
...

E cosa è stato trovato (e usato):

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

Extra: informazioni di debug da una connessione non riuscita - maggiori dettagli

Oppure, cosa è stato provato, ma è mancato.

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.

Modifica: aggiunto il 02 gennaio 2017

Nuova sezione - che dire delle chiavi che smettono di funzionare?

Sul mio server ho un client "vecchio" e il client "più recente" installato e ottengo comportamenti diversi collegandomi a un server. Qui il problema non è la corrispondenza errata della crittografia, ma l'uso di una coppia PKI arcaica , basata su DSA.

In breve, openssh-7 (.3) non invia più (per impostazione predefinita, forse per niente) chiavi pubbliche DSA.

Di seguito confronto l'output di due versioni di openssh
/ usr / bin / ssh (vecchia versione, lato sinistro) e
/ opt / bin / ssh (nuova versione, lato destro) - il comando è:

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

Mentre esegui la scansione dell'output di seguito, spero che noterai che i passaggi e i messaggi sono generalmente gli stessi. La differenza chiave deriva dalla stringa SSH2_MSG_SERVICE_ACCEPT

Quello che voglio che notiate è che la vecchia versione offre (ed è accettata dal "vecchio" server - la coppia di chiavi basata su DSA mentre il nuovo server non offre mai la chiave basata su DSA.

Nota: la 'soluzione' per questo è aggiungere (almeno una delle) coppie PKI basate su rsa, ecdsa o 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.                         |

Anche qui gli utenti si lamentavano delle chiavi con protocolli obsoleti quando sono passato a Debian 8.
Rui F Ribeiro

1
Ho dimenticato di dire - che per le mie finestre sono passato a stucco (ssh.com vende solo alle imprese) - sarei rimasto con ssh2se mi avessero accettato - principalmente per la facilità di fare scptrasferimenti dalla stessa finestra dissh
Michael Felt

1
Aggiorna il tuo client invece di usare vecchi client e abilitare algoritmi eventualmente rotti.
Jakuje,

1
Vedi Aggiorna le tue chiavi SSH! per maggiori dettagli, ma come dice @Jakuje, è una cattiva idea mantenere vecchie chiavi, vecchi client e vecchi algoritmi.
Stephen Kitt,

l'età della chiave non è un problema, ma il tipo e le dimensioni. "DSA" è fuori, "RSA" almeno 2048 bit. 'Meglio' è ecdsa. Come menziona @Jakuje - e di cosa tratta questa domanda e risposta - aggiorna i client - ma aggiorna anche i valori predefiniti. Come client puoi "richiedere" che un server usi algoritmi migliori non offrendo quelli deboli (peggio ancora rotti).
Michael Felt,
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.