Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | Fw: Odd key problem |
|---|---|
| Date: | Tue, 14 Nov 2006 16:19:23 +0000 |
Can anyone offer any insight to this problem?
Thanks
Begin forwarded message:
Date: Mon, 06 Nov 2006 08:30:04 +0000
From: Keith Edmunds <keith@midnighthax.com>
To: secureshell@securityfocus.com
Subject: Re: Odd key problem
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.
-- Keith Edmunds +---------------------------------------------------------------------+ | Tiger Computing Ltd | Helping businesses make the most of Linux | | "The Linux Company" | http://www.tiger-computing.co.uk | +---------------------------------------------------------------------+
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: Scp & sftp with no shell access or restricted access, Derek Martin |
|---|---|
| Next by Date: | Re: Scp & sftp with no shell access or restricted access, Rob Creely |
| Previous by Thread: | Re: Odd key problem, Keith Edmunds |
| Next by Thread: | SFTP Limited Availability, Chris Braster |
| Indexes: | [Date] [Thread] [Top] [All Lists] |