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
[EMAIL PROTECTED] reply 0
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 req
[EMAIL PROTECTED]
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.