why not option to automatically add pub key?

Daniel Kahn Gillmor dkg-openssh.com at fifthhorseman.net
Thu Jan 12 06:36:42 EST 2006


On January 11, stuge-openssh-unix-dev at cdy.org said:

 > On Wed, Jan 11, 2006 at 09:52:05AM -0500, Neal Becker wrote:
 > > Why can't this be automated?
 > 
 > Of course it can. But that doesn't mean it's a good idea.

i completely agree that making this mandatory behavior is not a good
idea.  However, i don't think Neal Becker was suggesting that.  He
asked if ssh could offer to add the client's public key to the remote
account's authorized_keys upon first connection (presumably only when
the keys stored in an agent aren't already present in the remote
account).

Again, i don't think even making the offer to the end user should be
the default behavior (too many people don't understand the
consequences of the known_hosts prompts as it is).  But i could see
how it might be nice to allow that as an option.

However, it's probably implementable with some sort of fancy
combination of ProxyCommand, ControlMaster/Path, and shell if
ssh-copy-id isn't streamlined enough for you.  

For example: ProxyCommand could spawn two processes: process A runs
netcat to remote port 22, and process B extracts your public keys from
your current agent and watches the ControlPath location.  Once the
ControlMaster is established properly (and the ControlPath socket is
set up), process B would check (over the socket) if the remote
authorized_keys contains your agent's keys.  If not, it would push
them over via something like ssh-copy-id.

 > OpenSSH doesn't want to dictate (and thereby limit) your access
 > control policy. Access control administration is left to the
 > administrator, which I think makes a lot of sense.

Unless i'm misunderstanding you, i have to disagree with this.  if the
administrator doesn't want the end user using pubkey auth at all, she
should disable it in the sshd config file.  If she's allowing pubkey
auth, it's entirely reasonable to allow the end user to set up and
manage his own keys.  The initial proposal was one possible mechanism
for a user to handle his own key management.

	--dkg




More information about the openssh-unix-dev mailing list