[gelöst] Sailfish OS SSH Authentication ERROR

Einrichten des lokalen Netzes, Verbindung zu anderen Computern und Diensten.
Antworten
Benutzeravatar
speefak
Beiträge: 439
Registriert: 27.04.2008 13:54:20

[gelöst] Sailfish OS SSH Authentication ERROR

Beitrag von speefak » 15.06.2019 14:09:51

Moin, ich habe seit einigen Wochen einen SSH Authentication Fehler zwischen meinem Debian 9 und SFOS System. Auf einem Debian 8 System tritt der Fehler nicht auf. In den Logs, weder auf dem Server noch auf dem Host finde ich keine Informationen. Was mir aber auffiel ist, das beim Debian 9 System ein Ordner innerhalb des .ssh auftaucht, der ein Programm ssh-agent enthält. Das ist mir neu und auf den Debian 8 Systeme ist dies nicht der Fall. Gab es in letzter Zeit SSH Updates oder wurde etwas im System umgestellt ?

Wo kann ich sonst noch Fehlerlogs schauen ?

EDIT : Debian 10 ist das schon aussagekräftiger : ssh_dispatch_run_fatal: Connection to XXX.XXX.XXX.XXX port 22: message authentication code incorrect
Zuletzt geändert von speefak am 16.06.2019 09:14:32, insgesamt 2-mal geändert.

Benutzeravatar
MSfree
Beiträge: 10686
Registriert: 25.09.2007 19:59:30

Re: SSH Authentication ERROR

Beitrag von MSfree » 15.06.2019 14:31:15

speefak hat geschrieben: ↑ zum Beitrag ↑
15.06.2019 14:09:51
Wo kann ich sonst noch Fehlerlogs schauen ?
Als erstes würde ich dem SSH-Client die Option -vvv mitgeben, also etwas in der Art:

Code: Alles auswählen

ssh -vvv user@server.top.level.domain

Benutzeravatar
speefak
Beiträge: 439
Registriert: 27.04.2008 13:54:20

Re: SSH Authentication ERROR

Beitrag von speefak » 15.06.2019 14:48:12

D8 ( OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.1t 3 May 2016 ) auf SFOS ( OpenSSH_7.9p1, OpenSSL 1.0.2o-fips 27 Mar 2018 ) funktioniert
D9 ( OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r 26 Feb 2019 ) auf SFOS ( OpenSSH_7.9p1, OpenSSL 1.0.2o-fips 27 Mar 2018 ) funktioniert nicht. ( keine Fehlermeldung außer Authentication error )
D10 ( OpenSSH_7.9p1, Debian-10, OpenSSL 1.1.1b 26 Feb 2019 ) auf SFOS ( OpenSSH_7.9p1, OpenSSL 1.0.2o-fips 27 Mar 2018 ) funktioniert nicht. ( Fehlermeldung : ssh_dispatch_run_fatal: Connection to XXX.XXX.XXX.XXX port 22: message authentication code incorrect )

Mich wundert warum es mit D10 auch nicht geht, zumal die Versionnummern ( beides OpenSSH_7.9p1 ) die gleichen sind.

Alles was ich fand war zum Thema MAC : https://stackoverflow.com/questions/532 ... cos-mojave

Was kann ich jetzt machen ? bin da grad ein wenig ratlos ?!

Debian 10 Log :

Code: Alles auswählen

ssh -vvvv  user@XXX.XXX.XXX.XXX
OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1b  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname XXX.XXX.XXX.XXX is address
debug2: ssh_connect_direct
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to XXX.XXX.XXX.XXX:22 as 'user'
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from XXX.XXX.XXX.XXX
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-ed25519 SHA256:iW79v0akETydpgYT/k3wVEJFDLgpAP8TBwFYfREjB9E
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from XXX.XXX.XXX.XXX
debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the ED25519 host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_rsa 
debug1: Will attempt key: /home/user/.ssh/id_dsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
debug1: Will attempt key: /home/user/.ssh/id_ed25519 
debug1: Will attempt key: /home/user/.ssh/id_xmss 
debug2: pubkey_prepare: done
debug3: send packet: type 5
ssh_dispatch_run_fatal: Connection to XXX.XXX.XXX.XXX port 22: message authentication code incorrect
Debian 9 Log :

Code: Alles auswählen

ssh -vvvv user@XXX.XXX.XXX.XXX
OpenSSH_7.4p1 Debian-10+deb9u6, OpenSSL 1.0.2r  26 Feb 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "XXX.XXX.XXX.XXX" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to XXX.XXX.XXX.XXX:22 as 'user'
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:43
debug3: load_hostkeys: loaded 1 keys from XXX.XXX.XXX.XXX
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,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,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-ed25519 SHA256:iW79v0akETydpgYT/k3wVEJFDLgpAP8TBwFYfREjB9E
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: record_hostkey: found key type ED25519 in file /home/user/.ssh/known_hosts:43
debug3: load_hostkeys: loaded 1 keys from XXX.XXX.XXX.XXX
debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the ED25519 host key.
debug1: Found key in /home/user/.ssh/known_hosts:43
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /home/user/.ssh/id_rsa (0x56030e41dce0), agent
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))
debug2: key: /home/user/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
Authentication failed.
Debian 8 Log :

Code: Alles auswählen

ssh -vvv user@XXX.XXX.XXX.XXX
OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to XXX.XXX.XXX.XXX [XXX.XXX.XXX.XXX] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u8
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9
debug1: match: OpenSSH_7.9 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "XXX.XXX.XXX.XXX" from file "/home/user/.ssh/known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /home/user/.ssh/known_hosts:13
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,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
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ssh-ed25519
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ED25519 9f:da:06:13:33:a2:73:fe:a2:bf:e7:f5:8d:a7:e2:e6
debug3: load_hostkeys: loading entries for host "XXX.XXX.XXX.XXX" from file "/home/user/.ssh/known_hosts"
debug3: load_hostkeys: found key type ED25519 in file /home/user/.ssh/known_hosts:13
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the ED25519 host key.
debug1: Found key in /home/user/.ssh/known_hosts:13
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x5637500bfe50),
debug2: key: /home/user/.ssh/id_dsa ((nil)),
debug2: key: /home/user/.ssh/id_ecdsa ((nil)),
debug2: key: /home/user/.ssh/id_ed25519 ((nil)),			## Hier bricht Debian 9 ohne Fehlermeldung ab, Debian 10 mit message code athentication incorrect
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/id_dsa
debug3: no such identity: /home/user/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug3: no such identity: /home/user/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug3: no such identity: /home/user/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
user@XXX.XXX.XXX.XXX's password: 

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: SSH Authentication ERROR

Beitrag von wanne » 15.06.2019 15:40:46

Ich würde mal tippen die Implementierung vom poly1305 in SFOS ist kaputt.

Meine Empfehlung zuerst einaml mit nem anderen Cipher/MAC einloggen:

Code: Alles auswählen

ssh -c aes256-ctr,aes128-gcm@openssh.com -m hmac-sha2-256-etm@openssh.com,hmac-sha2-512
Und dann in SFOS in der /etc/sshd_config die Ciphers manuell ohne poly1305 setzen:

Code: Alles auswählen

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
Zur verständlichkeit, warum ich um den MAC zu ändern auch die Ciphers setze:
Problem ist, dass poly1305 nur mit chacha20 funktioniert und deswegen verkauft ssh die Kombination chacha20-poly1305 als Cipher obwohl es auch einen MAC enthält.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
speefak
Beiträge: 439
Registriert: 27.04.2008 13:54:20

Re: SSH Authentication ERROR

Beitrag von speefak » 16.06.2019 09:09:34

Es funktioniert ;) Danke

Wie bist du darauf gekommen ? Durch die Logs ( wenn ja wo ) ? Falls so etwas wieder vorkommt würde ich das gerne selber analysieren und beheben können.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: SSH Authentication ERROR

Beitrag von mat6937 » 16.06.2019 11:21:37

speefak hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 09:09:34
Es funktioniert ...
Wie sind unter Debian 8 und Debian 9 (oder/und Debian 10) die Ausgaben von:

Code: Alles auswählen

strings $(which ssh) | grep -i poly1305
man ssh_config | fgrep -iA 5 -e poly1305
?

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: SSH Authentication ERROR

Beitrag von wanne » 16.06.2019 16:09:54

speefak hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 09:09:34
Wie bist du darauf gekommen ? Durch die Logs ( wenn ja wo ) ? Falls so etwas wieder vorkommt würde ich das gerne selber analysieren und beheben können.
Naja: Wenn der meint
message authentication code incorrect
Ist es jetzt nicht so weit hergeholt, dass was am MAC nicht stimmt. Dann habe ich im Log nachgeguckt und gesehen, dass bei Debian 8 umac-64-etm@openssh.com (was auch immer das für ein Algorithmus ist. Noch nie von gehört.) ausgehandelt wurde wurde während in neueren Versionen der poly1305 bevorzugt wurde.
Dazu das wissen, dass der poly1305 auf recht abstruse weise in den Cipher rein gebaut wurde...
Und man kann hat einen Indizienberg, der ziemlich erschlagend ist.
rot: Moderator wanne spricht, default: User wanne spricht.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: SSH Authentication ERROR

Beitrag von wanne » 16.06.2019 16:15:59

mat6937 hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 11:21:37
Wie sind unter Debian 8 und Debian 9 (oder/und Debian 10) die Ausgaben von:
Man macht das so:

Code: Alles auswählen

ssh -Q mac
bzw.

Code: Alles auswählen

ssh -Q cipher
Manpages sind ganz gerne mal veraltet was so Details angeht.
Die sind komisch sortiert: Was ganz unten steht wird am liebsten verwendet.
Beide haben den chacha20-poly1305@openssh.com drin. Bei Debian 8 wird aber wohl MAC/Cipher einzeln bevorzugt, während danach wohl die Ciphers mit integriertem MAC bevorzugt werden.
rot: Moderator wanne spricht, default: User wanne spricht.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: SSH Authentication ERROR

Beitrag von mat6937 » 16.06.2019 16:28:10

wanne hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 16:15:59
Manpages sind ganz gerne mal veraltet was so Details angeht.
Kann sein, aber strings und das verwendete binary sind nicht veraltet. Und wenn die manpage veraltet ist, sieht man das ja, wenn sie nicht zum binary passt.

In der manpage sind auch die default Werte für mac, cipher und Co. in einer bestimmte Reihenfolge angegeben.
Es geht auch zu sehen warum genau nur "chacha20-poly1305@openssh.com" (... an 1. Stelle bei den default-Angaben?) verwendet wird, wenn es auch andere brauchbare/funktionierende macs/cipher gibt.

EDIT:

BTW: Die Option "-Q" gibt es bei den "alten" Versionen (z. B. bei Debian 7?) von ssh noch nicht.

dufty2
Beiträge: 1709
Registriert: 22.12.2013 16:41:16

Re: [gelöst] Sailfish OS SSH Authentication ERROR

Beitrag von dufty2 » 16.06.2019 20:18:17

umac-64-etm@openssh.com:
Auf https://www.openssh.com/specs.html gibt es einen Hinweis:
draft-miller-secsh-umac-01 umac-64@openssh.com: a new transport-layer MAC.

chacha20-poly1305@openssh.com:
Die Bevorzugung könnte mit der sog. post-quantum-cryptography zu tun haben,
ist aber reine Vermutung von mir.

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: SSH Authentication ERROR

Beitrag von wanne » 17.06.2019 00:15:57

mat6937 hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 16:28:10
Es geht auch zu sehen warum genau nur "chacha20-poly1305@openssh.com" (... an 1. Stelle bei den default-Angaben?) verwendet wird, wenn es auch andere brauchbare/funktionierende macs/cipher gibt.
Das machen alle vernünftigen Cryptografischen Protokolle so. Du handelst am Anfang mit dem Keyexchange aus welches der Cipher ist, der der sicherste ist, den beide Seiten bevorzugen und nimmst dann konsequent den.
Damit muss ein potentieller Angreifer das stärkste ciphersuite knacken. Würden nacheinander durchprobiert werden, würde es reichen irgend eines zu knacken.
So bringt SSH zur Abwärtskompatibilität noch so kaputte Sachen wie RC4 und MD5 mit. Wenn deine Gegenstelle nichts anderes sprechen kann, kannst du noch das machen. Kann die Gegenstelle aber was anderes willst du das auf keinen Fall nutzen. Du willst aber eben auf keinen Fall, dass ein Angreifer dir so lange in die Verbindung spuckt bis du den nutzt.
Die Bevorzugung könnte mit der sog. post-quantum-cryptography zu tun haben,
aes256 ist genau so Quantensicher wie chacha20. chacha20 ist neuer und auf älterer Hardware wohl deutlich performanter. Eventuell haben sie ihn deswegen hochgezogen.
Daneben hat fehlerhaftes MAC-Handling in der Vergangenheit mittlerweile bestimmt ein duzend mal zu Schwachstellen in TLS-Implementierungen geführt. Da ist man deswegen jetzt (TLS 1.3) vollständig auf die Ciphers mit integriertem MAC umgestiegen, statt für beides eigene Algorithmen zu verwenden. Vielleicht haben die SSH-Leute auch davor angst gehabt.
rot: Moderator wanne spricht, default: User wanne spricht.

mat6937
Beiträge: 2925
Registriert: 09.12.2014 10:44:00

Re: SSH Authentication ERROR

Beitrag von mat6937 » 17.06.2019 09:10:07

wanne hat geschrieben: ↑ zum Beitrag ↑
17.06.2019 00:15:57
mat6937 hat geschrieben: ↑ zum Beitrag ↑
16.06.2019 16:28:10
Es geht auch zu sehen warum genau nur "chacha20-poly1305@openssh.com" (... an 1. Stelle bei den default-Angaben?) verwendet wird, wenn es auch andere brauchbare/funktionierende macs/cipher gibt.
Das machen alle vernünftigen Cryptografischen Protokolle so. Du handelst am Anfang mit dem Keyexchange aus welches der Cipher ist, der der sicherste ist, den beide Seiten bevorzugen und nimmst dann konsequent den.
Damit muss ein potentieller Angreifer das stärkste ciphersuite knacken. Würden nacheinander durchprobiert werden, würde es reichen irgend eines zu knacken.
So bringt SSH zur Abwärtskompatibilität noch so kaputte Sachen wie RC4 und MD5 mit. Wenn deine Gegenstelle nichts anderes sprechen kann, kannst du noch das machen. Kann die Gegenstelle aber was anderes willst du das auf keinen Fall nutzen. Du willst aber eben auf keinen Fall, dass ein Angreifer dir so lange in die Verbindung spuckt bis du den nutzt.
Es geht nicht darum was ich nutze, denn ich habe in meinen SSH-Servern und SSH-Clients, das was ich nutzen will genau konfiguriert und das funktioniert.

Es geht hier in diesem konkreten Fall um die (mehrere) default-Werte auf beiden Seiten (d. h. Server und Client). Wenn einer der default-Werte, und zwar "chacha20-poly1305@openssh.com" genutzt werden soll und dieser aus welchen Gründen auch immer nicht funktioniert, warum wird dann nicht mit dem zweit-sichersten default-Cipher versucht? Dann ist doch eine Vielzahl von default-Werten hier nutzlos.

Es ist auch klar, dass wenn im Server nur ein Cipher konfiguriert ist und mit dem Client ein anderer Cipher benutzt wird, ein genauer Hinweis gegeben wird, was hier beim TE aber nicht der Fall war.

EDIT:

Z. B.:

Code: Alles auswählen

ssh -v -c chacha20-poly1305@openssh.com xxxx
...
...
Unable to negotiate with <IP-Adresse> port 22: no matching cipher found. Their offer: aes256-ctr
oder:

Code: Alles auswählen

:~$ ssh -v -c blowfish-cbc <xxxx>
...
...
Unable to negotiate with 46.###.###.## port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes256-ctr
EDIT 2:

BTW: Wenn man auf die IP-Adresse des DF testet, kommt verständlicherweise die Meldung:

Code: Alles auswählen

Unable to negotiate with 144.##.###.### port 22: no matching cipher found. Their offer: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com

wanne
Moderator
Beiträge: 7447
Registriert: 24.05.2010 12:39:42

Re: [gelöst] Sailfish OS SSH Authentication ERROR

Beitrag von wanne » 17.06.2019 10:01:27

mat6937 hat geschrieben:Wenn einer der default-Werte, und zwar "chacha20-poly1305@openssh.com" genutzt werden soll und dieser aus welchen Gründen auch immer nicht funktioniert, warum wird dann nicht mit dem zweit-sichersten default-Cipher versucht?
wanne hat geschrieben:Damit muss ein potentieller Angreifer das stärkste ciphersuite knacken. Würden nacheinander durchprobiert werden, würde es reichen irgend eines zu knacken.
Im Fall von OpenSSH wäre das dann RC4 und MD5 was ziemlich einfach kaputt zu bekommen ist.
Nochmal um das fett für dich zum Mitschreiben: Der Fehler den dein SSH ausgibt heißt: Die Nachricht wurde von einer anderen Seite Manipuliert. (Lediglich meine Annahme war, dass der Server sich wohl eher nur verrechnet hat und die Daten schon falsch losgeschickt hat.) Objektiv sollte jedem Klar sein, dass es eine verdammt dumme Idee ist, nach dieser Feststellung einfach auf einen Cipher umzusteigen, den man als weniger sicher einschätzt.
Ich habe das nur deshalb empfohlen, weil die "unsichere" Methode aes256/sha512 heißt und ich genug Vertraue in die habe.
Selbst wenn du alle Ciphers als gleich sicher einschätzt, sollte es klar sein, dass es eine enorm viel größere Angriffsfläche verursacht, wenn es reicht einen (von 20) MAC angreifen zu können als wenn hart nur einer genutzt wird.
warum wird dann nicht mit dem zweit-sichersten default-Cipher versucht? Dann ist doch eine Vielzahl von default-Werten hier nutzlos.
Abwärtskompatibilität. Mit älteren Clienten spricht er ja noch andere MACs. Du siehst das schön bei deinem Debian 8. So bekommst du halt immer maximale Sicherheit unter dem Subset, dass beide Clienten können.
Zuerst mal ist so ein Mechanismus unumgänglich, wenn du updaten können willst. (Deswegen hat das praktisch jedes Kryptografische Protokoll drin.) Du kannst ja nicht alle Nutzer exakt gleichzeitig updaten. Zum zweiten erlaubt das halt mit dem selben Client unterschiedlich sichere Verbindungen aufzubauen. Dein Raspberry PI ist leistungsschwach steht aber dirket neben dir. Dem kannst du die Rechenintensiven Ciphers wie AES und DES3 abschalten. – Steht ja schließlich genau neben dir.
Auf deinen Server willst du das aber eher nicht dass dein Client dann mal RC4 nimmt, wenn der Angreifer das will.
rot: Moderator wanne spricht, default: User wanne spricht.

Benutzeravatar
speefak
Beiträge: 439
Registriert: 27.04.2008 13:54:20

Re: [gelöst] Sailfish OS SSH Authentication ERROR

Beitrag von speefak » 17.06.2019 19:03:53

Danke erstmal für die fundierten Infos ;)

Mich wunderte nur, dass es aus den Logs nicht ersichtlich war ( für mich zumindest ).

Antworten