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.




Network Security Secure-Shell
[Top] [All Lists]

Fw: Odd key problem

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>