this post was submitted on 14 Aug 2024
118 points (99.2% liked)

Linux

48684 readers
414 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 15 points 4 months ago (3 children)

As mentioned, -v (or -vv) helps to analyze the situation.

My theory is that you already have something providing ssh agent service, but that process is somehow stuck, and when ssh tries to connect it, it doesn't respond to the connect, or it accepts the connection but doesn't actually interact with ssh. Quite possibly ssh doesn't have a timeout for interacting with ssh-agent.

Using eval $(ssh-agent -s) starts a new ssh agent and replaces the environment variables in question with the new ones, therefore avoiding the use of the stuck process.

If this is the actual problem here, then before running the eval, echo $SSH_AUTH_SOCK would show the path of the existing ssh agent socket. If this is the case, then you can use lsof $SSH_AUTH_SOCK to see what that process is. Quite possibly it's provided by gnome-keyring-daemon if you're running Gnome. As to why that process would not be working I don't have ideas.

Another way to analyze the problem is strace -o logfile -f ssh .. and then check out what is at the end of the logfile. If the theory applies, then it would likely be a connect call for the ssh-agent.

[–] [email protected] 6 points 4 months ago (1 children)
[–] [email protected] 4 points 4 months ago

I guess it's worth checking if those names point to the expected binaries, but I also think it would be highly unlikely they would be anything else than just /usr/bin/ssh and /usr/bin/ssh-agent.

[–] [email protected] 3 points 4 months ago* (last edited 4 months ago) (2 children)

I didn't really follow the former part, but I can give you this:

strace -o logfile -f ssh -p 8322 [email protected] of when I get blank

[–] [email protected] 6 points 4 months ago

Please don't ignore the advice about SSH_AGENT_SOCK. It'll tell yoy what's going on (but not why).

[–] [email protected] 2 points 4 months ago (1 children)

At the end of the log you find:

822413 connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/gcr/ssh"}, 110) = 0
...
822413 read(4, 

meaning it's trying to interact with the ssh-agent, but it (finally) doesn't give a response.

Use the lsof command to figure out which program is providing the agent service and try to resolve issue that way. If it's not the OpenSSH ssh-agent, then maybe you can disable its ssh-agent functionality and use real ssh-agent in its place..

My wild guess is that the program might be trying to interactively verify the use of the key from you, but it is not succeeding in doing that for some reason.

[–] [email protected] 1 points 4 months ago* (last edited 4 months ago) (1 children)

I am not sure I "solved" this but when I add this to my startup script for my terminal (~/.zshrc):

SSH_AUTH_SOCK=/tmp/ssh-agent-$USER-socket
export SSH_AUTH_SOCK

it works then. I am not sure I'm still using the ssh agent, but at least it also does not cache my passphrase/private key

[–] [email protected] 1 points 4 months ago

Do you have that file? If not, then unset SSH_AUTH_SOCK will work just as well.

If it does exist, then I suppose it has good chances of working correctly :). ssh-add -l will try to use that socket and list your keys in the service (or list nothing if there are no keys, but it would still work without error).

[–] [email protected] 3 points 4 months ago (1 children)

My theory is that you already have something providing ssh agent service

in the past some xserver environments started an ssh-agent for you just in case of, and for some reason i don't remember that was annoying and i disabled it to start my agent in my shell environment as i wanted it.

also a possibility is tharlt there are other agents like the gpg-agent that afaik also handles ssh keys.

but i would also look into $HOME/.ssh/config if there was something configured that matches the hostname, ip, or with wildcards* parts of it, that could interfere with key selection as the .ssh/id_rsa key should IMHO always be tried if key auth is possible and no (matching) key is known to the ssh process, that is unless there already is something configured...

not sure if a system-wide /etc/ssh/ssh_config would interfere there too, maybe have a look there too. as this behaviour seems a bit unexpected if not configured specially to do so.

[–] [email protected] 1 points 4 months ago (1 children)

I am not sure I "solved" this but when I add this to my startup script for my terminal (~/.zshrc):

SSH_AUTH_SOCK=/tmp/ssh-agent-$USER-socket
export SSH_AUTH_SOCK

it works then. I am not sure I'm still using the ssh agent, but at least it also does not cache my passphrase.

[–] [email protected] 1 points 4 months ago

you should definitely know what type of authentication you use (my opinion) !! the agent can hold the key forever, so if you are just not asked again when connecting once more, thats what the agent is for. however its only in ram, so stopping the process or rebooting ends that of course. if you didn't reboot meanwhile maybe try unload all keys from it (ssh-add -D, ssh-add -L) and see what the next login is like.

btw: i use ControlMaster /ControlPath (with timeouts) to even reduce the number of passwordless logins and speed things up when running scripts or things like ansible, monitoring via ssh etc. then everything goes through the already open channel and no authentication is needed for the second thing any more, it gets really fast then.