Use codespaces.auto instead for the automatic ssh keys#5859
Conversation
|
I'm trying to decide on the behavior if there is some weird case where someone also already has a |
|
Hi! Thanks for the pull request. Please ensure that this change is linked to an issue by mentioning an issue number in the description of the pull request. If this pull request would close the issue, please put the word 'Fixes' before the issue number somewhere in the pull request body. If this is a tiny change like fixing a typo, feel free to ignore this message. |
josebalius
left a comment
There was a problem hiding this comment.
Do we want to write some sort of cleanup logic to delete the old key? If only for a couple of CLI releases? Otherwise, people might think we are polluting the .ssh directory? Just a thought.
mislav
left a comment
There was a problem hiding this comment.
Looks good! just some notes about backwards compatibility and clarity of the docs
mislav
left a comment
There was a problem hiding this comment.
Thanks for adding the migration logic!
There was a problem hiding this comment.
Re Windows failures: do you think it's possible that the The process cannot access the file because it is being used by another process failures are legitimate; i.e. that the gh process opens a file but forgets to close it?
|
@mislav yup, it's a difference in |
The new
sshfeature to automatically create public/private keys will not create the keys if~/.ssh/codespaces(the name of the automatically created key) already exists.At the same time, the
--helpmessage and docs for the same command recommend running commands likegh cs ssh --config > ~/.ssh/codespacesto createsshconfigs files. If someone has already created that file, the automatic keypair generation won't kick in. Which leads to some confusing messages.This PR does 2 things:
codespaces.autoto avoid the collision