2

(I've previously asked this question on SuperUser, but having tested that the key works fine on a MacBook running OSX, I feel the problem must be with Debian):

The problem

I've recently setup a Debian machine (and I don't have much experience with Debian), but I can't seem to properly connect to a server (192.168.1.31) using SSH.

After initial configuration it seems the server accepts my key, but the signature verification fails.

The initial configuration is how I always do it:

  1. Generate key (ssh-keygen -t rsa -b 4096 -C "my@email.com")
  2. Add it with ssh-add
  3. Register public key at SSH server

Debian client ssh dn@192.168.1.31 -vvv

OpenSSH_7.4p1 Debian-10+deb9u2, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /home/daniel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "192.168.1.31" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 192.168.1.31 [192.168.1.31] port 22.
debug1: Connection established.
debug1: identity file /home/daniel/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.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+deb9u2
debug1: Remote protocol version 2.0, remote software version 7.15 FlowSsh: Bitvise SSH Server (WinSSHD) 7.15
debug1: no match: 7.15 FlowSsh: Bitvise SSH Server (WinSSHD) 7.15
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.1.31:22 as 'dn'
debug3: hostkeys_foreach: reading file "/home/daniel/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/daniel/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.1.31
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
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: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,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: ecdh-sha2-1.3.132.0.10,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,ext-info-s
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp384
debug2: ciphers ctos: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,3des-ctr
debug2: ciphers stoc: aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr,3des-ctr
debug2: MACs ctos: hmac-sha2-256,hmac-sha1
debug2: MACs stoc: hmac-sha2-256,hmac-sha1
debug2: compression ctos: zlib,none
debug2: compression stoc: zlib,none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: ecdh-sha2-nistp256
debug1: kex: host key algorithm: ecdsa-sha2-nistp384
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256 compression: none
debug3: send packet: type 30
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ecdsa-sha2-nistp384 SHA256:kNkp4TIDsSbswddevanXAPgmtwXotVY4aojuRxZmOag
debug3: hostkeys_foreach: reading file "/home/daniel/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/daniel/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from 192.168.1.31
debug1: Host '192.168.1.31' is known and matches the ECDSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 4294967296 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 4294967296 blocks
debug2: key: /home/daniel/.ssh/id_rsa (0x55cab80f3c40), agent
debug2: key: dn@ordrestyring.dk (0x55cab80f7e90), agent
debug2: key: /home/daniel/.ssh/id_dsa ((nil))
debug2: key: /home/daniel/.ssh/id_ecdsa ((nil))
debug2: key: /home/daniel/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ecdsa-sha2-1.3.132.0.10,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)

debug2: we did not send a packet, disable method
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/daniel/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug2: input_userauth_pk_ok: fp SHA256:RZPLPu6tVldvSOMjzGq+57kt60onH4zTtiYmpQrWw9Y
debug3: sign_and_send_pubkey: RSA SHA256:RZPLPu6tVldvSOMjzGq+57kt60onH4zTtiYmpQrWw9Y
debug3: send packet: type 50
debug3: receive packet: type

Server response

Authentication attempt from 192.168.2.1:38794 with user name 'dn' suceeded partially. The public key supplied has been verified; requesting signature.
Authentication attempt from 192.168.2.1:38794 with user name 'dn' failed. Signature verification failed
Authentication attempt from 192.168.2.1:38794 with user name 'dn' suceeded partially. The public key supplied has been verified; requesting signature.
Authentication attempt from 192.168.2.1:38794 with user name 'dn' failed. Signature verification failed
Improve this question
5
  • 3
    Run the ssh command with -vvv switch to get more verbose log.
    – Jakuje
    Jan 6, 2018 at 16:39
  • snailbook.com/faq/publickey-userauth.auto.html
    – Ralph Rönnquist
    Jan 6, 2018 at 21:06
  • 3
    as per the log, the public key method is discarded, and the gssapi-with-mic method is attempted
    – Ralph Rönnquist
    Jan 6, 2018 at 21:13
  • @RalphRönnquist that is the point of debug log -- it will say why the pubkey method is rejected. But without the debug log, it is hard to guess.
    – Jakuje
    Jan 8, 2018 at 7:19
  • @Jakuje I have updated it to include the -vvv log.
    – Daniel
    Jan 8, 2018 at 9:33

1 Answer 1

Reset to default
4

What is important from the client point of view is the following part of the log:

debug1: Offering RSA public key: /home/daniel/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
debug2: input_userauth_pk_ok: fp SHA256:RZPLPu6tVldvSOMjzGq+57kt60onH4zTtiYmpQrWw9Y
debug3: sign_and_send_pubkey: RSA SHA256:RZPLPu6tVldvSOMjzGq+57kt60onH4zTtiYmpQrWw9Y
debug3: send packet: type 50

The first line offers the actual public key, the sixth line receives packet 60, which means SSH2_MSG_USERAUTH_PK_OK (corresponds to the first debug line on server). Then we are sending the actual signature using rsa-sha2-512 PK algorithm, but it is rejected (the answer packet is stripped from your log). This represents the second line on the server -- signature verification failed.

The SHA2 extension is buggy in OpenSSH. I already reported a bug #2799, which affects the communication with ssh-agent, in case you are using something different than OpenSSH one. It is directly related to your issue.

From what I see you are using something else (gnome-keyring? What is the output of echo $SSH_AUTH_SOCK?) and the server is not accepting wrong signatures provided by this agent. I already filled a bug for gnome-keyring to resolve this issue in there, but it will take some time to get into GNOME releases.

So for now, the best luck for you is to use ssh-agent or no agent at all. The following command should take you to your server:

SSH_AUTH_SOCK='' ssh dn@192.168.1.31

You can also patch your gnome-keyring or build it from master (some additional work). You should be able to use ECDSA keys too, but they are not yet in released gnome-keyring either.

Improve this answer
3
  • echo $SSH_AUTH_SOCK returns /run/user/1000/keyring/ssh. It seems your suggestion to prepend SSH_AUTH_SOCK='' allows me to connect! Thank you very much! :)
    – Daniel
    Jan 8, 2018 at 13:20
  • Yes, it is a gnome-keyring. So you are actually hitting this problem, that I tried to describe the OpenSSH developers, but with different server implementation than OpenSSH, which does it "right".
    – Jakuje
    Jan 8, 2018 at 13:22
  • Apparently, I have the same problem connecting from Ubuntu bionic to an OrangePi running an armbian with Debian stretch userland. I actually get debug3: receive packet: type 51 when I ssh with -vvv verbosity, which is likely the error indication you're referring to. ED25519 keys appear to work, though.
    – blubberdiblub
    Feb 24, 2018 at 15:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.