openssh unix dev - May 2017 - Golang CertChecker hostname validation differs to OpenSSH

> Uri (earlier in this thread) does answer this question clearly (that
    > the principal should be the hostname only), and, now that I've
found
    > PROTOCOL.certkeys, this seems to be spelt out unambiguously there too:
    
    In turn this means:
    One cannot expect several SSH services on a single host to be securely
distinguishable
    from each other by their particular service key. So if one of the SSH
services gets
    compromised all SSH services on this host are subject to MITM attacks with
the private
    key of the compromised service.
    

Yes and no. The standards wisely do not allow port numbers as a part of the DNS
identity.

On the other hand, nobody prevents you from having different key pairs for the
same host name, given to different servers that you insist should run on the
same host but on different ports (for example, I have one ?name?, but a pile of
certificates and corresponding key pairs for that name that I present to
different (appropriate) entities). You can even figure how to mix their port
numbers into their names (just don?t make it ?hostname? :).

I still think it?s not a very good idea to ?securely distinguish several SSH
services running on a single host?, but it seems entirely doable if you?re bent
on it.
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/168da314/attachment.bin>

Blumenthal, Uri - 0553 - MITLL wrote:
>  
>     > Uri (earlier in this thread) does answer this question clearly
(that
>     > the principal should be the hostname only), and, now that I've
found
>     > PROTOCOL.certkeys, this seems to be spelt out unambiguously there
too:
>     
> In turn this means: One cannot expect several SSH services on a single host
to be
> securely distinguishable from each other by their particular service key.
So if one of
> the SSH services gets compromised all SSH services on this host are subject
to MITM
> attacks with the private key of the compromised service.
> 
> Yes and no. The standards wisely do not allow port numbers as a part of the
DNS
> identity.
Ok, then one must access the different services by different FQDN.
> I still think it?s not a very good idea to ?securely distinguish several
SSH services
> running on a single host?, but it seems entirely doable if you?re bent on
it.
I'm curious: What's wrong to have a different SFTP-only service running
on a different
port besides the SSH server for admin shell access?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3829 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/42b12ad0/attachment-0001.bin>

> Yes and no. The standards wisely do not allow port numbers as a part of the
DNS
    > identity.
    
    Ok, then one must access the different services by different FQDN.
    
Apparently. That?s what everybody else has been doing for the last umpteen
years. ;-)

    > I still think it?s not a very good idea to ?securely distinguish
several SSH services
    > running on a single host?, but it seems entirely doable if you?re bent
on it.
    
    I'm curious: What's wrong to have a different SFTP-only service
running on a different
    port besides the SSH server for admin shell access?

Nothing that I can see off-hand. 

On the other hand, what?s your threat model? If it?s on the same host, how can I
compromise one key but not the other?

But as I said, while I would separate by virtual hosting and FQDN, you can craft
the certs the way you want ? except that the DNS name in the SAN cannot have the
port.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20170517/9e651dde/attachment.bin>