add .ssh/authorized_keys support for --sshcopyid #153
Conversation
We retain backwards compatibility, that is: we use keys from the agent by default. But if unavailable, we tap into the ~/.ssh/authorized_keys file (or whatever is specified by the $AUTHORIZED_KEYS_SOURCE environment). The target SSH directory can be changed with $AUTHORIZED_KEYS_TARGET. Closes: grml#151
There was a problem hiding this comment.
Thanks for providing the PR, @anarcat ! Finally managed to find some time looking into this, sorry for the delay!
I'm wondering though, whether we're putting too much magic into this, because what if someone expects --ssh-copy-id to only use keys provided via agent, but it fails and then it suddenly uses ~/.ssh/authorized_keys instead? Also maybe it might not be clear upfront that .ssh/authorized_keys needs to be set up?
On my very first try (without looking into the code ahead) I assumed it would take my existing ~/.ssh/id_rsa.pub file, so I didn't set up a ~/.ssh/authorized_keys file, while this didn't work as I thought it would. :)
Hmmmmm, what about instead introducing an option like --ssh-authfile or so (not really sure + happy with the naming yet :-/) which does what you implemented here?
Any other opinions (/cc @jkirk + @suntong)?
How would you like to use it in actual production usage?
| eerror "Error: copying '$AUTHORIZED_KEYS_SOURCE' to '$AUTHORIZED_KEYS_TARGET' failed" | ||
| eend 1 | ||
| bailout 1 | ||
| fi | ||
| else | ||
| eerror "Could not open a connection to your authentication agent or the agent has no identites." |
There was a problem hiding this comment.
I'd suggest to adjust the error message in line 1813 accordingly, so it's clear that either ssh-add -L or taking over ~/.ssh/ stuff didn't work?
| @@ -1809,6 +1811,17 @@ iface ${interface} inet dhcp | |||
| eend 1 | |||
| bailout 1 | |||
| fi | |||
| elif [ -f "$AUTHORIZED_KEYS_SOURCE" ]; then | |||
| einfo "copying '$AUTHORIZED_KEYS_SOURCE' to '$AUTHORIZED_KEYS_TARGET' as requested via --sshcopyid option." | |||
There was a problem hiding this comment.
nitpick: s/copying/Copying/ to make it consistent?
| einfo "copying '$AUTHORIZED_KEYS_SOURCE' to '$AUTHORIZED_KEYS_TARGET' as requested via --sshcopyid option." | ||
| mkdir -p "$AUTHORIZED_KEYS_TARGET" | ||
| chmod 0700 "$AUTHORIZED_KEYS_TARGET" | ||
| if cp "$AUTHORIZED_KEYS_SOURCE" "$AUTHORIZED_KEYS_TARGET" ; then |
There was a problem hiding this comment.
Should we ensure via chmod call that the authorized_keys file has the appropriate permissions?
There was a problem hiding this comment.
ah yes, or cp -p and just assume?
There was a problem hiding this comment.
The cp -p sounds like a good idea! 👍
| @@ -1809,6 +1811,17 @@ iface ${interface} inet dhcp | |||
| eend 1 | |||
| bailout 1 | |||
| fi | |||
| elif [ -f "$AUTHORIZED_KEYS_SOURCE" ]; then | |||
There was a problem hiding this comment.
Hm, what about installing ~/.ssh/id*.pub as ~/.ssh/authorized_keys if no ~/.ssh/authorized_keys exists?
There was a problem hiding this comment.
you mean all of them? that's kind of a different use case
i'm fine with that.
we use this to bootstrap hosts on hetzner. we give them ssh keys, they give us a rescue shell with ~/.ssh/authorized_keys populated with those keys, and we debootstrap from there. it's the reason why we use that file. the other reason is that we might not want to use |
Excellent! Do you have a nice naming for the option in mind? Similar to
Ah, excellent use case + idea!
Fair enough, let's forget my |
sounds fine.
i admit i'm a bit under the weather now so it might take some time before i get the time to look at this again. for now, we do this as a hook and i just figured i would bring that idea back upstream to see if it could land. i'll see if i can find the time to reshuffle this, but in the meantime feel free to beat me to it. :) |
What about naming this feature / option |
…opyauth Related to commit 07e835e and the discussion within #153 If execution of --sshcopyid fails, then user might want to be aware of it. So instead of implementing the copying of .ssh/authorized_keys as fallback of --sshcopyid, let's provide it via cmdline option --sshcopyauth. Reviewed-by: Chris Hofstaedtler Closes: #153
…opyauth Related to commit 07e835e and the discussion within #153 If execution of --sshcopyid fails, then user might want to be aware of it. So instead of implementing the copying of .ssh/authorized_keys as fallback of --sshcopyid, let's provide it via cmdline option --sshcopyauth. Reviewed-by: Chris Hofstaedtler Closes: #153
…opyauth Related to commit 07e835e and the discussion within #153 If execution of --sshcopyid fails, then user might want to be aware of it. So instead of implementing the copying of .ssh/authorized_keys as fallback of --sshcopyid, let's provide it via cmdline option --sshcopyauth. Reviewed-by: Chris Hofstaedtler Reviewed-by: Darshaka Pathirana Closes: #153
We retain backwards compatibility, that is: we use keys from the agent
by default. But if unavailable, we tap into the ~/.ssh/authorized_keys
file (or whatever is specified by the $AUTHORIZED_KEYS_SOURCE
environment).
The target SSH directory can be changed with $AUTHORIZED_KEYS_TARGET.
Closes: #151