I just double checked how openssh handled the case where the specific (eg, [foo.bar.com]:1234) cert-authority had the wrong key and the non-specific (foo.bar.com) had the correct key and this is what it says: debug1: Host 'foo.bar.com' is known and matches the ED25519-CERT host certificate. debug1: Found CA key in /etc/ssh/ssh_known_hosts:2 debug1: found matching key w/out port it does that no matter the order of specific/non-specific keys in /etc/ssh/ssh_known_hosts. that definitely feels wrong. On Sun, May 14, 2017 at 6:43 PM, Peter Moody <mindrot@xxxxxxxx> wrote: > specifically, this is what openssh says when connecting to a a host > with a otherwise valid hostcert on a non standard port > > debug1: Host 'foo.bar.com' is known and matches the ED25519-CERT > host certificate. > debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 > debug1: found matching key w/out port > > and this is when the port is correctly included in the known hosts > > debug1: Host '[foo.bar.com]:1234' is known and matches the > ED25519-CERT host certificate. > debug1: Found CA key in /etc/ssh/ssh_known_hosts:1 > > it definitely feels to me like the first behavior is incorrect. > > > > On Sun, May 14, 2017 at 6:39 PM, Peter Moody <mindrot@xxxxxxxx> wrote: >> I think I wrote the code in question for the golang library >> (https://github.com/golang/crypto/commit/527d12e53572562de9fd348d50e1ee4096803cec) >> >> my reading of the sshd manpage is that ssh is more permissive than it should be >> >> SSH_KNOWN_HOSTS FILE FORMAT : >> ... >> >> A hostname or address may optionally be enclosed within `[' and `]' >> brackets then followed by `:' and a non-standard port number. >> >> I actually noticed this last week and meant to email this list to ask >> the openssh devs of the 'correct' behavior. >> >> >> On Sun, May 14, 2017 at 5:24 PM, Adam Eijdenberg <adam@xxxxxxxxxxxxxx> wrote: >>> Hi all, >>> >>> Last week I noticed that the CertChecker in the Go implementation of >>> x/crypto/ssh seems to be doing host principal validation incorrectly >>> and filed the following bug: >>> https://github.com/golang/go/issues/20273 >>> >>> By default they are looking for a principal named "host:port" inside >>> of the certificate presented by the server, instead of just looking >>> for the host as I believe OpenSSH does. >>> >>> e.g. the following error is generated: >>> >>> ssh: handshake failed: ssh: principal "localhost:2022" not in the set >>> of valid principals for given certificate: ["localhost"] >>> >>> Before I ping the bug again, it would be good to get a second opinion >>> as to whether that behaviour is correct or not. >>> >>> Cheers, Adam >>> _______________________________________________ >>> openssh-unix-dev mailing list >>> openssh-unix-dev@xxxxxxxxxxx >>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
