PATCH: Support for encrypted host keys

[Nico Kadel-Garcia]

On Tue, Jan 31, 2012 at 7:53 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> On Tue, Jan 31, 2012 at 13:39:09 -0600, Nico Kadel-Garcia wrote:
>> On Tue, Jan 31, 2012 at 9:56 AM, Daniel Kahn Gillmor
>> <dkg at fifthhorseman.net> wrote:
>> > Hi Zev--
>> >
>> > On 01/28/2012 04:25 AM, Zev Weiss wrote:
>> >> I recently found myself wanting to run sshd with passphrase-protected host keys rather than the usual unencrypted format, and was somewhat surprised to discover that sshd did not support this. ?I'm not sure if there's any particular reason for that, but I've developed the below patch (relative to current CVS at time of writing) that implements this. ?It prompts for the passphrase when the daemon is started, similarly to Apache's behavior with encrypted SSL certificates.
>> >
>> > Can i ask what threats you hope to mitigate with this approach? ?What
>> > are your concerns about having a cleartext ~/.ssh/known_hosts?
>>
>> One concern is pretending to be the designated host with host keys
>> retrieved from backup or from sites that deploy identical hostkeys via
>> a base installation or replicated OS image in virtualization. Since
>> the sshd handles passwords in many environments, and there is no
>> mechanism for revocation or expiration of host keys in
>> $HOME/.ssh/known_hosts, the ability to pretend to be a previously
>> accepted host with stolen keys has presented a functional security
>> issue since SSH was first written.
>
> With recent versions of OpenSSH, 5.4p1 and later, you can use host
> certificates which can be expired or revoked. Also, regarding backups,
> it is possible to exclude the private keys from being backed up. That is
> only a partial solution and would mean that new keys would have to be
> created if the old ones were lost.

Good! I'm afraid I'm compelled by work to spend my time with older
releases in "production" environments. And until more deployed clients
support this as well, I'm afraid it will still be a risk. But it's a
good move.

And yes, backing up the private keys is important if you have to
restore the host. It's *precisely* the sort of data you want to be
able to build an authorized replacement host.

>> Too many sites are far, far too careless with these keys since "if
>> they're inside our network, we have much bigger problems", both of
>> which I've heard on various occasions.
>
> Note that encrypting the private keys would break ssh-keysign (unless
> some agent mechanism is used). Thus, this would break hostbased
> authentication in cases where the client host used encrypted host keys.

Excellent point!