5

Client is Ubuntu 16.04 with keychain, server is FreeBSD 10.3. There is only one key in ~/.ssh/authorized_keys on the server (this key is ECDSA p521 and not RSA), and the client has both private and public key inside ~/.ssh. The problem is the client keeps sending all RSA keys available in its ~/.ssh first - see this verbose output:

OpenSSH_7.2p2 Ubuntu-4, OpenSSL 1.0.2g-fips  1 Mar 2016
debug1: Reading configuration data /home/manuth/.ssh/config
debug1: /home/manuth/.ssh/config line 1: Applying options for r2d2.manuth.life
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to r2d2.manuth.life [103.12.163.90] port 900.
debug1: Connection established.
debug1: identity file /home/manuth/.ssh/dqar type 3
debug1: key_load_public: No such file or directory
debug1: identity file /home/manuth/.ssh/dqar-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2 FreeBSD-20160310
debug1: match: OpenSSH_7.2 FreeBSD-20160310 pat OpenSSH* compat 0x04000000
debug1: Authenticating to r2d2.manuth.life:900 as 'manuth'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp521
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
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp521 SHA256:awtuO9udROeroYOv3GJ8Z6xcHt4IQhjNkcKQ6eavuik
debug1: Host '[r2d2.manuth.life]:900' is known and matches the ECDSA host key.
debug1: Found key in /home/manuth/.ssh/known_hosts:10
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: manuth@wackypc
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: manuth@wackypc
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: manuth@wackypc
debug1: Authentications that can continue: publickey
debug1: Offering ECDSA public key: /home/manuth/.ssh/dqar
debug1: Server accepts key: pkalg ecdsa-sha2-nistp521 blen 172
debug1: Authentication succeeded (publickey).
Authenticated to r2d2.manuth.life ([103.12.163.90]:900).

Still the same output even when I specify this in ~/.ssh/config on the client:

host r2d2.manuth.life
IdentityFile ~/.ssh/dqar
Port 900

Tried removing all keys from keychain but no help. If I add an RSA public key to the server then specify the RSA private key in ~/.ssh/config on the client, it does pick up the RSA key straight away.

  • Are there any relevant messages in the server logs ? – Iain Oct 8 '16 at 4:49
  • @Hanginoninquietdesperation nothing wrong in the server's log. I think the problem is with the client. – Manuth Chek Oct 8 '16 at 4:52
  • It probably is the client but there is no harm in checking as frequently the server will provide useful information in diagnosing problems. For example, if the client's file perms are incorrect it will log this whilst the client does not. – Iain Oct 8 '16 at 4:55
  • For the best security you should be using ed25519 keys anyway. – Michael Hampton Oct 8 '16 at 8:04
  • @MichaelHampton So how safe is ed25519 compared to ECDSA p521 that I'm using? – Manuth Chek Oct 8 '16 at 8:34
3

Found the answer from here: https://linux-audit.com/using-ed25519-openssh-keys-instead-of-dsa-rsa-ecdsa/

Basically I have to add this to the client's ~/.ssh/config:

IdentitiesOnly yes

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.