Golang CertChecker hostname validation differs to OpenSSH

Adam Eijdenberg adam at continusec.com
Tue May 16 08:52:34 AEST 2017

On Tue, May 16, 2017 at 2:38 AM, Peter Moody <mindrot at hda3.com> wrote:
> your proposed patch removes both checks though. I think you'd want to
> modify knownhosts.go if you want to support not including non-standard
> ports in IsHostAuthority.

My intention wasn't to modify both checks - I'm currently only
concerned with principal checking, although I can see how your recent
patch (as implemented) would also be affected (so if we do change
anything here, we'll probably need to refactor a little).

Let me give a concrete example, currently our certificates (OpenSSH
server, and OpenSSH client) look like this and everything works great:


However, if I write a Go client (which requires a port number be
specified in their Dial string):

    log.Println(ssh.Dial("tcp", "auth.example.local:10000", &ssh.ClientConfig{
        HostKeyCallback: (&ssh.CertChecker{}).CheckHostKey,

I get the following error, before even attempting to evaluating

    ssh: handshake failed: ssh: principal "auth.example.local:10000"
not in the set of valid principals for given certificate:
["auth.example.local" "auth.example.com.au"]

If I want a certificate to work with OpenSSH server, and both Go and
OpenSSH clients, I need to re-generate a certificate like this:


That doesn't seem right, and I think the Go principal evaluation is
incorrect, but I would like a second opinion.

(that code in Go also seems to be at least 3 years old)

More information about the openssh-unix-dev mailing list