Nach einem Update können Nebenwirkungen auftreten. Bei OpenSSH ändern sich die Standardeinstellungen häufig. OpenBSD (die OpenSSH warten / entwickeln) hat die Richtlinie von OpenBSD, sich keine Gedanken über die Abwärtskompatibilität zu machen. Dies kann Dinge "zerbrechen", die, wie gelesen, gut funktionieren.
Es gibt einen massiven Hinweis - dass ich nicht bemerkt habe, als mir das zum ersten Mal passiert ist (über die GUI-Oberfläche, und ich habe es einfach weggeklickt und war 'wütend' auf 'dummes Update - neue Version ist kaputt'. Es stellt sich heraus, dass die neue Version war nicht kaputt - aber OpenBSD / OpenSSH beginnt mit dem Ändern der Standardeinstellungen für den Schlüsselaustausch ab OpenSSH-6.7p1. Siehe: http://www.openssh.com/txt/release-6.7 , insbesondere:
Änderungen seit OpenSSH 6.6
Potenziell inkompatible Änderungen
sshd (8): Der Standardsatz von Chiffren und MACs wurde geändert,
um unsichere Algorithmen zu entfernen. Insbesondere sind CBC-Chiffren und arcfour *
standardmäßig deaktiviert.
Der vollständige Satz von Algorithmen bleibt verfügbar, wenn er
explizit über die Optionen ciphers und MACs sshd_config konfiguriert wird .
Mein Problem ist, dass ich einen alten Client habe, der keine der neuen Standardeinstellungen hat, sodass keine Verbindung hergestellt werden kann.
Zwei Lösungspfade: Fix / Patch des Servers oder - Fix / Patch des Clients.
Serverlösung: Bringen Sie "alte" Einstellungen zurück, damit "alte" Clients weiterhin eine Verbindung herstellen können, dh - freundlich zu vorhandenen Clients - bearbeiten Sie die Datei sshd_config und fügen Sie (genug) der alten Chiffren zurück.
Die wichtigsten Zeilen zum Ändern / Hinzufügen in sshd_config sind:
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
Einfach hinzufügen:
# 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
Lösung 2 - Reparieren / Ersetzen des Clients
Eine einfache Möglichkeit, um festzustellen, welche Chiffren Ihr aktueller Client unterstützt (unter der Annahme einer CLI), besteht darin, ssh -hfestzustellen, ob dies Folgendes bietet:
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
Ein weiterer nützlicher Befehl ist: ssh -V
ssh2: SSH Secure Shell 3.2.9 Windows Client
Product: SSH Secure Shell for Workstations
License type: none (non-commercial)
Meiner - war - ein sehr alter Client - für meinen Desktop. Wenn Sie oben schauen, können Sie sehen, dass es keinen der - 15 Jahre später - bevorzugten Algorithmen unterstützt, nicht einmal einen -cbr (rotierend), nur -cbc (Blockkopie).
Wenn Ihr Client keine Option zur Bereitstellung der unterstützten Schlüssel usw. hat (OpenSSH sollte die Option haben -Q), stellen Sie einfach eine Verbindung zu sich selbst her, z. B. ssh -v localhostund es gibt Zeilen wie diese, die Ihnen mitteilen, dass bekannt ist:
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
...
Und was gefunden (und verwendet) wurde:
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: Debug-Informationen von einer fehlgeschlagenen Verbindung - weitere Details
Oder was versucht, aber verpasst wurde.
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.
Bearbeiten: hinzugefügt am 02. Januar 2017
Neuer Abschnitt - Was ist mit Schlüsseln, die nicht mehr funktionieren?
Auf meinem Server sind ein "alter" Client und der "neueste" Client installiert - und es wird ein anderes Verhalten beim Herstellen einer Verbindung zu einem Server angezeigt. Hier geht es nicht um Verschlüsselungsfehler, sondern um die Verwendung eines archaischen PKI-Paares - basierend auf DSA.
Kurz gesagt, openssh-7 (.3) sendet keine öffentlichen DSA-Schlüssel mehr (standardmäßig, möglicherweise überhaupt nicht).
Unten vergleiche ich die Ausgabe von zwei Versionen von openssh
/ usr / bin / ssh (alte Version, linke Seite) und
/ opt / bin / ssh (neue Version, rechte Seite) - der Befehl lautet:
${version}/ssh -v user@host date
Ich hoffe, Sie bemerken beim Durchsuchen der folgenden Ausgabe, dass die Schritte und Meldungen im Allgemeinen gleich sind. Der Hauptunterschied kommt nach der Zeichenfolge SSH2_MSG_SERVICE_ACCEPT
Ich möchte, dass Sie feststellen, dass die alte Version das DSA-basierte Schlüsselpaar bietet (und vom "alten" Server akzeptiert wird -, während der neue Server niemals den DSA-basierten Schlüssel anbietet.
Hinweis: Die "Lösung" hierfür besteht darin, (mindestens eines der) PKA-Paare auf der Basis von rsa, ecdsa oder ed25519 hinzuzufügen.
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. |