With regard to this problem, reiterated below, one suggestion was that I
examine $SSH_AUTH_SOCK on SystemB for each user. Interestingly the
user who cannot subsequently log on to SystemC does not have
$SSH_AUTH_SOCKET set; the user who can log on to SystemC does have it set.
Running with loglevel to DEBUG3 on systemB shows that the successful
user has these lines in the log file, but these same lines are missing
from the unsuccessful user (the logs are otherwise identical save for
PIDs, usernames, etc):
---------------------------------------------------
debug1: server_input_channel_req: channel 0 request
auth-agent-req@openssh.com reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req
auth-agent-req@openssh.com
debug1: temporarily_use_uid: 1000/1000 (e=1000/1000)
debug1: restore_uid: (unprivileged)
debug1: channel 1: new [auth socket]
---------------------------------------------------
So my question now is: why does one user end up with those lines in the
log, and thus getting $SSH_AUTH_SOCKET set, but the other user does not?
Thanks,
Keith
Original problem:
There are three systems, systemA, systemB and systemC. Two users each
have an account on all three. Systems B and C both enforce the use of
ssh keys (PasswordAuthentication and ChallengeResponseAuthentication
both set to 'no').
From SystemA, both users can "ssh -A systemB" and are logged in
successfully via keys.
Having logged into SystemB from SystemA as shown above, one user can
"ssh -A systemC" and log in successfully; the other user, with the
same command, gets "Permission denied (publickey)".
From SystemA, both users can "ssh -A systemC" and are logged in
successfully via keys.
I cannot understand why the second user cannot login SystemA - SystemB
- SystemC while the other user can.
