3
why can't I connect to my ssh server UNLESS I enter eval "$(ssh-agent -s)" first?
(lemmy.dbzer0.com)
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.
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
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 uselsof $SSH_AUTH_SOCK
to see what that process is. Quite possibly it's provided bygnome-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 thelogfile
. If the theory applies, then it would likely be aconnect
call for the ssh-agent.I didn't really follow the former part, but I can give you this:
strace -o logfile -f ssh -p 8322 pi@192.168.2.223 of when I get blank
At the end of the log you find:
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.
I am not sure I "solved" this but when I add this to my startup script for my terminal (~/.zshrc):
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
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).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
.