Search code examples
sshdnsssh-keysopensshdnssec

why do my sshfp records don't match?


I have a dnssec zone and want to publish ssh keys in, using sshfp.

So, on the host which holds the keys, I run :

 ssh-keygen -r localhost

which gives me the results :

 localhost IN SSHFP 1 1 223458a4e3f4cae23a2365a127a9fc5dbfc4df0b
 localhost IN SSHFP 1 2 cf04e11c129c465e90afc3fc68b0a9c6f256e7c3dc2f0ef0d61557f5848cc2bb

then I placed it in my dnssec zone (which the correct hostname obviously), resign the zone and check by a dig query. Everything is fine.

And then, a ssh query says the thing is wrong :

  stephane@luciole:~$ ssh -v -o VerifyHostKeyDNS=yes host
  OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
  debug1: Reading configuration data /home/stephane/.ssh/config
  debug1: /home/stephane/.ssh/config line 1: Applying options for host
  debug1: Reading configuration data /etc/ssh/ssh_config
  debug1: /etc/ssh/ssh_config line 19: Applying options for *
  debug1: Connecting to host [2001:16d8:d0:205::5]
  debug1: Connection established.
  debug1: identity file /home/stephane/.ssh/id_rsa type 1
  debug1: identity file /home/stephane/.ssh/id_rsa-cert type -1
  debug1: identity file /home/stephane/.ssh/id_dsa type -1
  debug1: identity file /home/stephane/.ssh/id_dsa-cert type -1
  debug1: identity file /home/stephane/.ssh/id_ecdsa type -1
  debug1: identity file /home/stephane/.ssh/id_ecdsa-cert type -1
  debug1: identity file /home/stephane/.ssh/id_ed25519 type -1
  debug1: identity file /home/stephane/.ssh/id_ed25519-cert type -1
  debug1: Enabling compatibility mode for protocol 2.0
  debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Debian-7
  debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
  debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000
  debug1: SSH2_MSG_KEXINIT sent
  debug1: SSH2_MSG_KEXINIT received
  debug1: kex: server->client aes128-ctr [email protected] none
  debug1: kex: client->server aes128-ctr [email protected] none
  debug1: sending SSH2_MSG_KEX_ECDH_INIT
  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
  debug1: Server host key: ECDSA 4d:57:c1:77:2d:cf:6b:46:d4:83:24:3c:b7:d4:0d:67
  debug1: found 4 insecure fingerprints in DNS
  debug1: mismatching host key fingerprint found in DNS
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
  Someone could be eavesdropping on you right now (man-in-the-middle attack)!
  It is also possible that a host key has just been changed.
  The fingerprint for the ECDSA key sent by the remote host is
  4d:57:c1:77:2d:cf:6b:46:d4:83:24:3c:b7:d4:0d:67.
  Please contact your system administrator.
  Update the SSHFP RR in DNS with the new host key to get rid of this message.
  debug1: checking without port identifier
  The authenticity of host '[host] ([2001:16d8:d0:205::5])' can't be established.
  ECDSA key fingerprint is 4d:57:c1:77:2d:cf:6b:46:d4:83:24:3c:b7:d4:0d:67.
  No matching host key fingerprint found in DNS.
  Are you sure you want to continue connecting (yes/no)?

So why am I having ?

I am now working in safe environnement, local network with direct access to the server. There's no MITM possible.


Solution

  • when creating the dns sshfp, I didn't noticed I had only four sshfp RR whereas I have three ssh keys (two sshfp per key).

    So I return and generated one by one the sshfp in the ssh directory, and compaired with what I had in dns. It appeared I didn't have the ecdsa key.

    So I specifically generate the sshfp with this key. Registered it in the zone, and signed it. After that, when I tried a ssh connection with VerifyHostKeyDNS and verbose, ssh said well it founded the correct ssh fingerprints !

    cd /etc/ssh
    ls
    ssh_config
    ssh_dsa_key
    ssh_dsa_key.pub
    ...
    
    ssh-keygen -r host -f ssh_host_ecdsa_key