Golang CertChecker hostname validation differs to OpenSSH

[Peter Moody]

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 at hda3.com> 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 at continusec.com> 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 at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev