Golang CertChecker hostname validation differs to OpenSSH

[Peter Moody]

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 at hda3.com> 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 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