why not option to automatically add pub key?

[Neal Becker]

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.