why not option to automatically add pub key?

Neal Becker ndbecker2 at gmail.com
Thu Jan 12 07:22:09 EST 2006

Daniel Kahn Gillmor wrote:

> 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

I'd like to add, that surely there's no security impact here.  If you can do
it manually, all this does is make it more convenient.

More information about the openssh-unix-dev mailing list