0

I've been facing an interesting issue for a few weeks now. Part of our fleet is only reachable via a jump-host.

In the past I had no issues w/ logging into the jump-host from my workstation using ssh -A and maintain a session for extended periods of time [yes, I know that's bad practice, not here for a lecture on a foul habit =}], and connect on from there to other machines w/o password entry as expected.

Now every so often going to my uxterm with the active session to the jump host gives me a 

Permission denied (publickey)

If I disconnect, and w/o restarting the agent connect to the jump host again, all works as before.

How do I diagnose what's going on there?

Extra information: my workstation is Ubuntu 16.04, the jump host is 14.04, recently upgraded from 12.04.

tink
  • 1,036
  • 11
  • 19

1 Answers1

2

When using agent forwarding, ssh actually forwards the UNIX socket to a directory in /tmp and the sets SSH_AUTH_SOCK to point to it.

Effectively, thus means that only a new remote shell will inherit SSH_AUTH_SOCK. Older sessions, will keep pointing to a socket that no longer exists. You could just export it again if you don't want to open a new shell

Ginnungagap
  • 1,998
  • 8
  • 9
  • But why is the socket being torn down these days? It used to work OK for years. :) – tink May 15 '17 at 20:36
  • It's not so much that it gets torn down than it gets moved, when reconnecting the socket is placed in a random folder – Ginnungagap May 15 '17 at 20:53
  • Maybe I didn't quite explain myself well enough, I'm not reconnecting. I'm keeping a session to the jump host open, sometimes for weeks. But in the last two months or so (since the upgrade to 14.04 of the jump host) I can't connect to other machines from the jump host anymore w/ "public key denied" after a couple of days. – tink May 15 '17 at 21:11
  • What does `ssh-add -l` say when run on the jump host? – Ginnungagap May 15 '17 at 21:15
  • Could not open a connection to your authentication agent. – tink May 15 '17 at 21:59
  • How bizarre ... this kind of implies that the session was torn down and re-established w/o me "losing" the session from the desktops perspective. – tink May 15 '17 at 22:01
  • 1
    I guess at this point bug tracking would be trying to let a session live for a while with `ssh` in verbose mode, see what gives – Ginnungagap May 15 '17 at 22:06
  • fwiw, I too experience the same thing - long-lived ssh connections (e.g. months!) lose ability to access ssh agent on origin machine after a day or so. I guess this is a very rare usage as few seem to experience this bug. Only workaround is to create a new connection that inherits different ssh-agent env params. Copying env vars from new working connection to old connection also works. – Chris Warth Jan 17 '19 at 19:30