An SSH Glitch

Written by: Paul Rubin

Primary Source: OR in an OB World

Something weird happened with SSH today, and I’m documenting it here in case it happens again.

I was minding my own business, doing some coding, on a project that is under version control using Git. After committing some changes, I was ready to push them up to the remote (a GitLab server here at Michigan State University). I had already set up the GitLab account with my RSA public key, and I had done previous pushes successfully. Today, suddenly, the push failed with a message that boiled down to the server not recognizing my key.

After the usual amount of fruitless messing around, I ran the command

ssh-add -l

in a terminal window. This is supposed to list the keys that the ssh-agent program recognizes. Oops! The response was “The agent has no identities.”In other words, my public/private key pair, which I’ve been using for ages, was not being seen by ssh-agent.

I don’t know if this is the result of a software update or a boot anomaly. The keys were right where they were supposed to be, in ~/.ssh, unchanged. Restarting ssh-agent did not help. What fixed it was to run

ssh-add ~/.ssh/id_rsa

in a terminal. I did that when I first set up the keys, and I don’t know why I had to do it again. We’ll see if I’m forced to do it a third time.

After that last command, ssh-add -l showed the “fingerprint” of my key. I still could not push to the GitLab server, though. So, on the GitLab server, I tried to install my public key (with a new name) and was told the fingerprint matched my existing key. In desperation, I deleted the old key and installed the “new” public key (the one with the same fingerprint as the key just deleted). Bear in mind that at no point in this mess did I generate new keys; the key I installed was the same one previously installed (and just deleted). For whatever reason, that worked; the server accepted the commit.

<sigh>Now I have to make sure that every other server using my public key also recognizes my digital signature.</sigh>

Update: The business about using ssh-add may be a red herring. I just checked my laptop (which uses the same public/private key pair and has the same Git projects on it. I ran ssh-add -l and again got the “no identities” message. Then I ran a Git “pull” command (from the NetBeans IDE), using my key, and (after giving a password to unlock my keyring) it worked! I then tried ssh-add -l again, just to make sure unlocking the keyring had not caused ssh-agent to sober up, and the response was still “no identities”. So having no listed identities apparently does not prevent applications from using the key pair.

On the home PC, I frequently (but not always) get the prompt to unlock my keyring when banging on a Git server. It didn’t happen today, and I didn’t think anything of that at the time. I’m now left to wonder if the whole problem with logging into the server had something to do with (a) the keyring being locked and (b) the system, for whatever reason, never asking me to unlock it?

Or maybe it’s just gremlins. The little buggers tend to be a bit unpredictable.

The following two tabs change content below.
I'm an apostate mathematician, retired from a business school after 33 years of teaching mostly (but not exclusively) quantitative methods courses. My academic interests lie in operations research. I also study Tae Kwon Do a bit on the side.

Latest posts by Paul Rubin (see all)