| Summary: | Support for encrypted host keys | ||
|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Zev Weiss <zevweiss> |
| Component: | sshd | Assignee: | Assigned to nobody <unassigned-bugs> |
| Status: | CLOSED FIXED | ||
| Severity: | enhancement | CC: | djm, markus, pcerny, zev |
| Priority: | P2 | ||
| Version: | 5.9p1 | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 2076 | ||
| Attachments: | |||
|
Description
Zev Weiss
2012-02-01 03:22:09 AEDT
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 |