I have my own ssh server (on raspberry pi 5, Ubuntu Server 23) but when I try to connect from my PC using key authentication (having password disabled), I get a blank screen. A blinking cursor.
However, once I enter the command eval "$(ssh-agent -s)" and try ssh again, I successfully login after entering my passphrase. I don’t want to issue this command every time. Is that possible?
This does not occur when I have password enabled on the ssh server. Also, ideally, I want to enter my passphrase EVERYTIME I connect to my server, so ideally I don’t want it to be stored in cache or something. I want the passphrase to be a lil’ password so that other people can’t accidentally connect to my server when they use my PC.
Without the ssh-agent invocation:
- what does
ssh-add -Lshow? - what is the original SSH_AUTH_SOCK value?
- what is listening to that? (Use
lsof)
This kind of stuff often happens because there’s a ton of terrible advice online about managing ssh-agent - make sure there’s none if that baked into your shellrc.
ssh-add -L
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqS5l(redacted)f0phb8x+fUV1w== username@computername
echo $SSH_AUTH_SOCK
/run/user/1000/gcr/ssh
lsof $SSH_AUTH_SOCK
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
gcr-ssh-a 778406 username 3u unix 0x000000007e25ee6b 0t0 30290 /run/user/1000/gcr/ssh type=STREAM (LISTEN)
gcr-ssh-a 778406 username 6u unix 0x0000000020f5b559 0t0 2096642 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 12u unix 0x00000000a6756d60 0t0 2100347 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 15u unix 0x00000000625cb05a 0t0 2261237 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 21u unix 0x00000000d0b214f9 0t0 2261238 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 23u unix 0x00000000a2f197fe 0t0 2349665 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 27u unix 0x00000000da22a130 0t0 2349668 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 29u unix 0x000000004f7a1723 0t0 2365382 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 33u unix 0x00000000e26976b3 0t0 2365389 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 35u unix 0x00000000b8185a8a 0t0 2375648 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 39u unix 0x00000000ba41030c 0t0 2375649 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 41u unix 0x000000006867cb01 0t0 2380999 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 45u unix 0x0000000091384b95 0t0 2381008 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 47u unix 0x00000000d5b28b08 0t0 3729149 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
gcr-ssh-a 778406 username 51u unix 0x00000000f65088aa 0t0 3731006 /run/user/1000/gcr/ssh type=STREAM (CONNECTED)
All before issuing the ssh-agent
Search for /run/user/1000/gcr/ssh on the Internet. I’m on my phone and didn’t find the solution, but I’m sure you’ll find it.
Okay, that agent process is running but it looks wedged: multiple connections to the socket seem to be opened, probably your other attempts to use ssh.
The ssh-add output looks like it’s responding a bit, however.
I’d use your package manager to work out what owns it and go looking for open bugs in the tool.
(Getting a trace of that process itself would be handy, while you’re trying again. There may be a clue in its behaviour.)
The server reaponse seems like the handshake process is close to completing. It’s not immediately clear what’s up there I’m afraid.
Is this problem a recurring one after a reboot?
If it is it warrants more effort.
If not and you’re happy with rhe lack of closure, you can potentially fix this: kill the old agent (watch out to see if it respawns; if it does and that works, fine). If it doesn’t, you can (a) remove the socket file (b) launch ssh-agent with the righr flag (-a $SSH_AGENT_SOCK iirc) to listen at the same place, then future terminal sessions that inherit the env var will still look in the right place. Unsatisfactory but it’ll get you going again.
