Mention the importance of using the default SSH key location

[edbennett]

In episode 7, we state: "We want to use the default file, so just press Enter."

At a recent Carpentries UK community call, one instructor mentioned that they derailed a lesson because they chose a non-default location for the key, because of the specific setup of the computer they were using. However, OpenSSH only looks for keys in the default locations.

If this is something that other instructors have encountered difficulty with, is it worth adding a sentence after the one quoted above? Something along the lines of "(If you choose another location here, then the key won't automatically be detected when you come to use it. However, you can use the -i option to specify it explicitly.)"

[jcohen02]

Following a brief discussion on Carpentries Slack, I was going to open a separate issue to report on some experiences/issues with the recently added SSH key elements of the Git material, however, we experienced this specific issue at a workshop we've just run so adding some comments here (I'll ref this issue from the main "SSH experiences" issue):

• Our initial concern was that simply accepting the default key location could cause problems for some users - where people have got an existing setup to access, e.g. a local HPC cluster, an office desktop, etc, if this is configured to use the default key file and it's using the same key type, overwriting the default key file will break existing setup. While it does prompt you to confirm if you want to overwrite an existing key, telling people to use the default name may incentivise people to just say 'yes'. Indeed, in our session there were people were unfamiliar with SSH but had existing setup that had been put in place for them. As a result, our git instructor used a different key file name, specified with the -f switch to the ssh-keygen which led us to a lot of further complexity!

• As @edbennett suggests, you can simply specify the -i option to tell SSH which key to use - this worked fine for the next section where learners are asked to test the connection to GitHub using ssh -T [email protected] and we simply told them to add the -i option with the path to their key. However, things got rather more complex when it came to trying to push to a remote repository...

• To the best of my knowledge, there's no way to specify the -i switch directly to the git push command? Having always had an SSH config file set up with settings for github.com, I'd never encountered this issue before. We ended up having to tell people to either specify the GIT_SSH_COMMAND env var on the command line (thanks SO 🙂), i.e. $ GIT_SSH_COMMAND='ssh -i <full path to SSH key file>' git push origin main or to set up an SSH config file. I think setting up SSH agent may also be an option here? We didn't want to get into explaining to people how to edit their .bash_profile/.bashrc and permanently setting GIT_SSH_COMMAND at this stage but I suppose that would also be something to consider. Either way, this was time consuming and detracted from the process of teaching git.

I understand the reasons for adding the SSH key material and I'm not sure of an immediate solution - this is seems to be something that learners need to get set up and should have some understanding of - but certainly from our recent experience, it requires a lot more time to cover this effectively so just wanted to offer some feedback based on recent experiences.

[kekoziar]

In episode 7, we state: "We want to use the default file, so just press Enter."

At a recent Carpentries UK community call, one instructor mentioned that they derailed a lesson because they chose a non-default location for the key, because of the specific setup of the computer they were using. However, OpenSSH only looks for keys in the default locations.

If this is something that other instructors have encountered difficulty with, is it worth adding a sentence after the one quoted above? Something along the lines of "(If you choose another location here, then the key won't automatically be detected when you come to use it. However, you can use the -i option to specify it explicitly.)"

I have not experienced this issue; however, perhaps we need to include a line or callout about the possible problem, and add an instructor note that they need to test their machine prior to using it for the workshop.

[edbennett]

I have not experienced this issue; however, perhaps we need to include a line or callout about the possible problem, and add an instructor note that they need to test their machine prior to using it for the workshop.

I agree that a callout would be one way to hopefully avoid this.

I don't think testing the machine prior to using it for the workshop will help however—the problem is caused by the instructor deviating from the notes during the lesson. (In fact, the check before the lesson should be that they can't log in to GitHub by SSH, as the instructor should be starting from the same clean configuration that most learners will.)