Created attachment 2125 [details] Patch to implement support for encrypted host keys in sshd (Copy/paste from this post to the mailing list: http://marc.info/?l=openssh-unix-dev&m=132774431906364&w=2) 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 [attached] 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. My initial implementation instead operated by passing the passphrase along to the rexec child, but I decided I thought it was slightly nicer to decrypt the key once and pass it along rather than redoing it every time. I can send the previous version if that would be preferred though -- this key-passing version does have some resulting ugliness in its handling of options.num_host_key_files, as described in a comment in the patch.
Created attachment 2303 [details] Incomplete patch for sshd to use ssh-agent for hostkeys From mailing list post: ...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). This version also (somewhat unnecessarily) bundles public keys into the sensitive_data struct, but I didn't really see a more appropriate place to stash those.
djm's mailing list reply: > 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...
(In reply to Zev Weiss from comment #2) > djm's mailing list reply: > > > 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... problems: 1) calling both readconf() for ssh_config and sshd_config easy fix: rename struct options for either client or server config 2) however: i don't like the idea of having ssh-keysign run the parser code while running w/ uid 0 we should avoid running that much code in a setuid tool... perhaps just disallow ssh-keysign for ssh-agent-setups :)
oops, i've forgotten that we already have ServerOptions
Created attachment 2306 [details] (relative) patch that makes rekey work
Created attachment 2307 [details] full patch (against openbsd cvs)
Comment on attachment 2307 [details] full patch (against openbsd cvs) Looks good >@@ -1906,9 +1947,11 @@ main(int ac, char **av) > buffer_init(&loginmsg); > auth_debug_reset(); > >- if (use_privsep) >+ if (use_privsep) { > if (privsep_preauth(authctxt) == 1) > goto authenticated; >+ } else if (compat20) >+ auth_conn = ssh_get_authentication_connection(); Should agent use be dependent on a config option or a different environment variable to SSH_AUTH_SOCK? I'd worry about people restarting sshd and having it pick up their own agent...
> 2) however: i don't like the idea of having ssh-keysign > run the parser code while running w/ uid 0 At least in this case the configs are root-owned. > we should avoid running that much code in a setuid tool... > perhaps just disallow ssh-keysign for ssh-agent-setups :) I don't think we would get many complaints about this :)
Created attachment 2308 [details] full patch, including HostKeyAgent option, no ssh-keysign changes
Comment on attachment 2308 [details] full patch, including HostKeyAgent option, no ssh-keysign changes nice!
Created attachment 2309 [details] updated patch (against openbsd cvs) fixes HostKeyAgent=SSH_AUTH_SOCK and only opens the agent connection if HostKeyAgent is actually configured.
Markus has committed this. It will be in openssh-6.3. Thanks!
Close all resolved bugs after 7.3p1 release