RFC: encrypted hostkeys patch

[Damien Miller]

On Mon, 24 Jun 2013, Zev Weiss wrote:

> Hi,
> 
> About a year and a half ago I brought up the topic of encrypted hostkeys
> and posted a patch
> (http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2), and while the
> general reaction seemed receptive to the idea, a few problems were pointed
> out with the implementation (UI issues, ssh-keysign breakage).
> 
> I've finally had some spare time in which to get back to this, and I've
> written a new patch which has the daemon talking to an ssh-agent for
> private key operations, as suggested in the previous conversation -- the
> current version of the patch can be found below.

Wow - thanks! This was on my list of things to do and I'm very glad
that you beat me to it.

Could I ask you to create a bug at https://bugzilla.mindrot.org/ and
attach your patch and the below comments there so we can track and review
them?

> And, assuming things look OK thus far, I'm considering how best to handle
> the ssh-keysign problem.  Since it's executed by a user's ssh client, it
> won't have the server's SSH_AUTH_SOCK environment variable, so finding the
> socket to connect to is slightly tricky -- any problems with changing it to
> a (configurable) static, globally-known path?  Assuming not, then there's
> the question of *where* that would be configured -- sshd would need to know
> it, but ssh-keysign reads ssh_config, not sshd_config; requiring the user
> to configure the same path in both seems undesirable, as does having either
> one loading the other's config file.  I guess making it compile-time
> configurable would sort of work, but also doesn't seem like a great
> solution.  Any thoughts or suggestions on this?  Having a static,
> configurable socket path does seem nice otherwise, so sshd could just spawn
> its own agent passing "-a $SOCKETPATH" if it encounters an encrypted
> hostkey on startup, rather than, say, relying on an init script to launch
> ssh-agent and export the SSH_AUTH_SOCK variable to sshd (though I suppose
> there's really nothing stopping it from doing that anyway without a static
> socket path).

I think it is down to adding another ssh_config option to configure a well-
known agent socket for ssh-keysign or making ssh-keysign read sshd_config
too. The latter might be desirable, since then it could detect which keys
are actually in use. That being said, making it read ssh_config would be
more flexible if people ran multiple ssh instances on their hosts. Maybe
there is some third option that hasn't occurred to me...

-d