openssh bugs - Jan 2017 - [Bug 2673] New: Multiple ssh keys for a given server

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

            Bug ID: 2673
           Summary: Multiple ssh keys for a given server
           Product: Portable OpenSSH
           Version: -current
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: george.shuklin at gmail.com

There are some cases when server may have few server keys, each of
those is valid.

Examples: 
1) server booting from golden image. Golden image has 'build-in' host
ssh key which is changed after system configuration management
application set up proper ssh key for server.
2) server may reboot between two different operating systems, each
using own host ssh key.
3) DynDNS-related shuffling between few servers (at given time server 
is occupying on of the few known IPs, and is causing false alerts if
that IP was known to be used by previous server).

Right now there is no way to say ssh client 'both keys are valid for a
given server', which cause users one of the following actions:

1. Use set of ssh options to prevent key learning
2. Use ssh-keygen -R to remove old key and confirm new one on the next
connect, repeat on each host ssh key change (e.g. reboot to different
OS).

Both of those actions loosen attention on 'spoofed ssh keys' alert and
therefore significantly endanger overall security of ssh-related
workflow. Malicious agent may use those alerts to persuade personnel
mistakenly trusting wrong key (due to repeated and often false positive
alerts, actual and valid alert would have been ignored and processed as
false positive). 

Proposition: permit multiple host keys for a given server name and/or
IP address.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to George Shuklin from comment #0)
[...] 
> 1) server booting from golden image. Golden image has 'build-in'
> host ssh key which is changed after system configuration management
> application set up proper ssh key for server.
The down side is that anyone with access to the golden image could MITM
connections.
> 2) server may reboot between two different operating systems, each
> using own host ssh key.
Copy one set of host keys and use it on both OSes.
> 3) DynDNS-related shuffling between few servers (at given time
> server  is occupying on of the few known IPs, and is causing false
> alerts if that IP was known to be used by previous server).
Use CheckHostIP=no in the config for such hosts.

[...]
> Proposition: permit multiple host keys for a given server name
> and/or IP address.
Anyway, that's already possible but for different host key types.  You
could set HostKeyAlgorithms=ssh-rsa for one host and
HostKeyAlgorithms=ssh-ed25519 on the other.

I think having multiple keys of the same type valid for one host is a
risk, though.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to George Shuklin from comment #0): 
> 1) server booting from golden image. Golden image has 'build-in'
> host ssh key which is changed after system configuration management
> application set up proper ssh key for server.
Use "ssh -o HostKeyAlias=golden-image" when connecting to the newly
imaged system until the keys are changed.  This also protects against
trivial MITM at that point (not from anyone with access to the image
though).

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

--- Comment #3 from George Shuklin <george.shuklin at gmail.com> ---
(In reply to Darren Tucker from comment #1)
> (In reply to George Shuklin from comment #0)
> [...] 
> > 1) server booting from golden image. Golden image has
'build-in'
> > host ssh key which is changed after system configuration management
> > application set up proper ssh key for server.
> 
> The down side is that anyone with access to the golden image could
> MITM connections.
Yes, there is a risk, but it's less than 'use -R every time'. Adding
additional keys is not default configuration, so unexpected users
wouldn't be affected.
> > Proposition: permit multiple host keys for a given server name
> > and/or IP address.
> 
> Anyway, that's already possible but for different host key types. 
> You could set HostKeyAlgorithms=ssh-rsa for one host and
> HostKeyAlgorithms=ssh-ed25519 on the other.
> 
> I think having multiple keys of the same type valid for one host is
> a risk, though.

Is any reason why to have two different keys with different algo is OK,
but to have two different keys with same algo is not OK?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

--- Comment #4 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to George Shuklin from comment #3)
[...]
> Yes, there is a risk, but it's less than 'use -R every time'.
Adding
> additional keys is not default configuration, so unexpected users
> wouldn't be affected.
Some users will do insecure things but that doesn't mean we should
weaken the host key checking for those who don't.
> Is any reason why to have two different keys with different algo is
> OK, but to have two different keys with same algo is not OK?
It's an artefact of the way the host key matching works, not a
deliberate feature.

In recent versions of OpenSSH the server will inform the client of all
of its host keys (via the "hostkeys-00 at openssh.com" extension) and
if
the client wants to (via UpdateHostKeys) it will update the known_hosts
file.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |WONTFIX
                 CC|                            |djm at mindrot.org
             Status|NEW                         |RESOLVED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
I agree with Darren here - this seems like a niche-case solution that
is fairly likely to trap common-case users, sorry. BTW, host
certificates may present a possible solution to your problem.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2673

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #6 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.