Created attachment 2503 [details] sshd_config same on both machines. When doing host based authentication using signed host keys you need to have the connecting host in /etc/ssh/ssh_known_hosts. @cert-authority is not enough. When running sshd in debug-mode it seems it first accepts the cert with CA. but then requires the actual host to be in ssh_known_hosts anyway. Hm only one attachment? the ssh_known_hosts has only one line looking something like: @cert-authority * ssh-rsa AAAA....
Peter, could you attach the complete sshd -ddd from a session demonstrating this problem?
Created attachment 2507 [details] sshd -ddd
Created attachment 2508 [details] ssh -vvv
Like I said before, as far as I can see the problem is here: https://github.com/openssh/openssh-portable/blob/master/auth2-hostbased.c#L189-L222 -- host_status = check_key_in_hostfiles(pw, key, lookup, _PATH_SSH_SYSTEM_HOSTFILE, options.ignore_user_known_hosts ? NULL : _PATH_SSH_USER_HOSTFILE); -- This block does not take in to account the possibility that the hostkey can be a certificate while code surrounding it does.
No, that block is correct. That is where the search for the @cert-authority entry occurs.That is how load_hostkeys() gets called, which does find the @cert-authority entry. From the sshd -ddd output, the certificate passes the basic tests (certificate type, validity period, principals) and an applicable CA entry is found. However, the certificate ends up being rejected. That could be a mismatch between the key used to sign the certificate and the entry in the ssh_known_hosts file. What do you get for the output of ssh-keygen -Lf on your certificate and does the fingerprint for the signing CA match the fingerprint for the @cert-authority entry?
Looking at the debug output more closely, it looks like the client is not attempting to use any certificates. The server logs just three hostbased authentication attempts, and the 'Failed hostbased' messages all indicate that these were plain keys. As an aside, it probably isn't a good idea to create certificates for all the supported key types. In most cases, just one (or perhaps two) certificates should be sufficient. Since hostbased will try all host keys and certificates until it succeeds, you could easily exhaust the allowed number of authentication attempts if the ssh_known_hosts or shosts.equiv files are misconfigured.
Hm, but it uses the cert to validate the autheticity of the server (which works). Is my sshd misconfigured in some way?
It it the certs it is using: Nov 16 22:55:02 m3 sshd[63451]: Failed hostbased for petera from port 53372 ssh2: DSA bf:c3:bf:01:c2:fd:98:9e:3f:98:00:bd:84:08:ce:eb, client user "petera", client host "m4" Nov 16 22:55:02 m3 sshd[63451]: Failed hostbased for petera from port 53372 ssh2: ECDSA fd:59:de:a9:0f:47:bb:89:79:46:57:10:4c:ba:fe:8b, client user "petera", client host "m4" Nov 16 22:55:02 m3 sshd[63451]: Failed hostbased for petera from port 53372 ssh2: RSA 37:9b:5a:34:02:27:32:8f:03:f8:c3:b1:0b:be:d0:2e, client user "petera", client host "m4" --- ssh_host_dsa_key-cert.pub: Type: ssh-dss-cert-v01@openssh.com host certificate Public key: DSA-CERT bf:c3:bf:01:c2:fd:98:9e:3f:98:00:bd:84:08:ce:eb Signing CA: RSA 47:94:00:4c:dc:65:0c:c5:72:87:a1:04:a6:53:42:4a ssh_host_ecdsa_key-cert.pub: Type: ecdsa-sha2-nistp256-cert-v01@openssh.com host certificate Public key: ECDSA-CERT fd:59:de:a9:0f:47:bb:89:79:46:57:10:4c:ba:fe:8b Signing CA: RSA 47:94:00:4c:dc:65:0c:c5:72:87:a1:04:a6:53:42:4a ssh_host_rsa_key-cert.pub: Type: ssh-rsa-cert-v01@openssh.com host certificate Public key: RSA-CERT 37:9b:5a:34:02:27:32:8f:03:f8:c3:b1:0b:be:d0:2e Signing CA: RSA 47:94:00:4c:dc:65:0c:c5:72:87:a1:04:a6:53:42:4a
Ok. I will apologize now. The problem was that the cert files was not world readable on the client machine...
It would probably be helpful to add some debug output in the client to indicate which keys are being tried. Currently, it just indicates that it tried hostbased authentication, but doesn't indicate which key or cert was used. I'll look into that.
Created attachment 2509 [details] Show which hostkey is used by the client Add a debug() statement to reveal which hostkey is being used in userauth_hostbased(). More precisely, indicate the key type rather than the actual filename. The patch is against -current.
Created attachment 2510 [details] Tweak previous patch
Patch applied to -current
I just configured a hostbased authentication setup with certificates and found that it worked fine. Your problem is probably this: > debug2: userauth_hostbased: chost m4.. Your host seems to think that it's name is "m4.", probably because of a misconfigured /etc/hosts. Hostbased authentication is pretty sensitive to this and the logging at both ends is pretty terrible. I'll look at improving it.
Hi! Please look at my comment #9. Sorry.
ok; I've added some more debugging that might help future cases.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1