SSH przestał działać po aktualizacji serwera? Co się stało?

9

Korzystam z połączeń SSH opartych na PKI od ponad 10 lat. Nagle po aktualizacji serwera niektóre połączenia przestały działać. Używam tych samych kluczy PKI, których używałem od lat (każdy serwer ma swoje własne klucze, mam mały zestaw kluczy osobistych).

Praca - wygląda następująco:

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

Nie działa wygląda następująco:

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

Co się zmieniło?

openssh 
— Michael Felt
źródło
2
Ilekroć aktualizuję lub ponownie konfiguruję SSH, zazwyczaj natychmiast próbuję otworzyć inne połączenie SSH, pozostawiając otwarte połączenie otwarte do debugowania. Takie podejście pomogłoby w debugowaniu w scenariuszach takich jak twój. Czy nadal masz dostęp do serwera? A może próbujesz debugować to po stronie klienta bez dostępu do przeglądania dzienników po stronie serwera, dopóki problem nie zostanie rozwiązany?
— kasperd
1
Na szczęście zawsze miałem dostęp do serwera. Zasadniczo, stosując aktualizacje, staram się być „na konsoli” - z powodów, o których wspomniałeś. Próbowałem tutaj pokazać, jak debugować, gdy działa dla niektórych (np. Najnowszy kit), ale nie dla innych (np. 14-letni klient ssh, który nie zna ulepszonych algorytmów szyfrowania, kex i mac.
— Michael Felt

Odpowiedzi:

14

Po aktualizacji - mogą pojawić się efekty uboczne. Z OpenSSH - wartości domyślne często się zmieniają. OpenBSD (który utrzymuje / rozwija OpenSSH) ma politykę OpenBSD, aby nie martwić się kompatybilnością wsteczną. Może to „zepsuć” rzeczy, które, jak czytamy, działają dobrze.

Jest ogromna wskazówka - że nie zauważyłem, kiedy to mi się po raz pierwszy przydarzyło (używając interfejsu GUI, po prostu kliknąłem go i „byłem zły” na „głupią aktualizację - nowa wersja jest zepsuta”. nie został uszkodzony - ale OpenBSD / OpenSSH zaczyna zmieniać domyślne ustawienia wymiany kluczy, zaczynając od OpenSSH-6.7p1, patrz: http://www.openssh.com/txt/release-6.7 , zauważalnie:

Zmiany od OpenSSH 6.6

Potencjalnie niezgodne zmiany

  • sshd (8): Domyślny zestaw szyfrów i adresów MAC został zmieniony w celu
    usunięcia niebezpiecznych algorytmów. W szczególności szyfry CBC i arcfour *
    są domyślnie wyłączone.

    Pełny zestaw algorytmów pozostaje dostępny, jeśli zostanie skonfigurowany
    jawnie za pomocą opcji sshd_config szyfrów i adresów MAC.

Mój problem polega na tym, że mam starego klienta, który nie ma żadnych nowych ustawień domyślnych, więc nie może się połączyć.

Dwie ścieżki rozwiązania: napraw / załataj serwer lub - napraw / załataj klienta.

Rozwiązanie serwerowe: przywróć „stare” ustawienia, aby „starzy” klienci mogli się dalej łączyć, to znaczy - przyjazny dla istniejących klientów - edytować plik sshd_config i dodać (wystarczającą) liczbę starych szyfrów.

Kluczowe linie do zmiany / dodania w sshd_config to:

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

Poprostu dodaj:

# 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

Rozwiązanie nr 2 - napraw / wymień klienta

Prostym sposobem na sprawdzenie, jakie szyfry obsługuje Twój obecny klient (przy założeniu CLI) ssh -hi sprawdzenie, czy to zapewnia:

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

Kolejnym przydatnym poleceniem jest: ssh -V

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

Mój - był - bardzo stary klient - na mój pulpit. Patrząc powyżej, widać, że nie obsługuje żadnego z - 15 lat później - preferowanych algorytmów, nawet jednego -cbr (rotacja), tylko -cbc (block-copy).

Jeśli twój klient nie ma opcji dostarczenia obsługiwanych kluczy itp. (OpenSSH powinien mieć taką opcję -Q), po prostu rozpocznij połączenie ze sobą, np. ssh -v localhostI istnieją takie linie, aby powiedzieć, że wat jest znany:

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

A co zostało znalezione (i wykorzystane):

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

Dodatkowo: informacje debugowania z nieudanego połączenia - więcej szczegółów

Lub, co próbowano, ale przegapiono.

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.

Edycja: dodano 02-sty-2017

Nowa sekcja - co z kluczami, które przestają działać?

Na moim serwerze mam zainstalowanego „starego” klienta i „najnowszego” klienta - i uzyskuję inne zachowanie podczas łączenia się z serwerem. Tutaj problemem nie są niezgodności szyfrów - lecz zastosowanie archaicznej pary PKI - opartej na DSA.

Krótko mówiąc, openssh-7 (.3) nie wysyła już (domyślnie, być może wcale) kluczy publicznych DSA.

Poniżej porównuję dane wyjściowe dwóch wersji openssh
/ usr / bin / ssh (stara wersja, lewa strona) i
/ opt / bin / ssh (nowa wersja, prawa strona) - polecenie to:

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

Podczas przeglądania poniższych danych wyjściowych mam nadzieję, że zauważysz, że kroki i komunikaty są zasadniczo takie same. Kluczowa różnica występuje po ciągu SSH2_MSG_SERVICE_ACCEPT

Chcę, abyście zauważyli, że stara wersja oferuje (i jest akceptowana przez „stary” serwer - parę kluczy opartą na DSA, podczas gdy nowy serwer nigdy nie oferuje klucza opartego na DSA.

Uwaga: „rozwiązaniem” tego problemu jest dodanie (przynajmniej jednej) pary kluczy PKI opartych na rsa, ecdsa lub 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.                         |
— Michael Felt
źródło
Kiedy uaktualniłem do Debiana 8, tutaj też narzekali użytkownicy na klucze z przestarzałymi protokołami.
— Rui F Ribeiro,
1
Zapomniałem wspomnieć - że dla moich okien przełączyłem się na kit (ssh.com sprzedaje tylko firmom) - zostałby, ssh2gdyby mnie zaakceptowali - głównie ze względu na łatwość wykonywania scpprzelewów z tego samego okna cossh
— Michael Felt
1
Zaktualizuj swojego klienta zamiast korzystać z dawnych klientów i włączać potencjalnie uszkodzone algorytmy.
— Jakuje,
1
Zobacz Uaktualnij klucze SSH! aby uzyskać więcej informacji, ale jak mówi @Jakuje, nie jest dobrym pomysłem przechowywanie starych kluczy, starych klientów i starych algorytmów.
— Stephen Kitt,
wiek klucza nie jest problemem, imho - ale typ i rozmiar. „DSA” jest wyłączone, „RSA” co najmniej 2048-bitowe. „Lepszy” to ecdsa. Jak wspomina @Jakuje - i o co chodzi w tych pytaniach - aktualizuj klientów - ale także aktualizuj ustawienia domyślne. Jako klient możesz „zażądać”, że serwer używa lepszych algorytmów, nie oferując słabych (gorzej uszkodzonych).
— Michael Felt
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.