[Bug 1974] Support for encrypted host keys

[bugzilla-daemon at mindrot.org]

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

Zev Weiss <zev at bewilderbeest.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zev at bewilderbeest.net
   Attachment #2125|0                           |1
        is obsolete|                            |

--- Comment #1 from Zev Weiss <zev at bewilderbeest.net> ---
Created attachment 2303
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2303&action=edit
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.

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