110
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
All before issuing the ssh-agent
It's the gnome key ring ssh agent.
It's possible that this has popped up a window asking gor permission / a passphrase / something and you're not seeing that.
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.
I searched. When I change this variable (path), it works. So in the startup script for my terminal (~/.zshrc) I added this:
Now it works, but I'm not sure why. Anything BUT
/run/user/1000/gcr/ssh
works I thinkOkay, 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.reboot makes no difference. A new terminal gives the symptoms from the start.
I think I found a bad workaround. If I add this script to ~/.zshrc (because I'm not using bash but zsh)
then it works. But I think I'm still using the ssh agent which I actually should not be using. At least it's asking for the passphrase every time, which is nice. Even in the same terminal after ssh logout.
EDIT: The first two lines do the trick as well:
EDIT: If I change this SSH_AUTH_SOCK to ANYTHING else, it also works. So
/run/user/1000/gcr/ssh
does not work. I gave ample permission to this file, so that cannot be the problem. Perhaps BECAUSE this is a file. I think the SSH_AUTH_SOCK should point to a nonexisting file because then it makes temporarily a special file that it needs. Ok I'm just shooting in the dark.Minimise your windows one at a time and check that the gnome keyring hasn't popped up a dialog box sonewhere behind everything else that's asking you if it's okay to proceed.
No unfortunately not... Would've been a real pain.
Have you considered storing your keys unencrypted? In this case ssh doesn't need the agent or a password.
Yes it's not as secure, but for me it's good enough considering my systems at home are not doing anything important. If you have an encrypted home partition it's just as secure when your partition is unmounted.