[21359] in Athena Bugs
Fwd: strange problem with a user ssh'ing to a particular athena machine
daemon@ATHENA.MIT.EDU (Nicholas Knouf)
Fri Jan 24 17:20:28 2003
Date: Fri, 24 Jan 2003 17:20:25 -0500
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=US-ASCII; format=flowed
From: Nicholas Knouf <nknouf@MIT.EDU>
To: bugs@mit.edu
Content-Transfer-Encoding: 7bit
Message-Id: <08FA4000-2FEA-11D7-B4E4-00039347B6FE@mit.edu>
I thought that I would forward this to people on this list as well, in
the hopes of getting a solution.
Nick Knouf
Lab Manager, Kanwisher Lab
Begin forwarded message:
> From: Nicholas Knouf <nknouf@MIT.EDU>
> Date: Fri Jan 24, 2003 4:40:41 pm US/Eastern
> To: linux-help@MIT.EDU
> Cc: linux-bugs@MIT.EDU
> Subject: strange problem with a user ssh'ing to a particular athena
> machine
>
> Hi All,
>
> I hope someone has some suggestions for me, because this problem has
> me (and some other people I've talked to) stumped.
>
> I have a server, call it server1, (running Athena 9.1.11 which will be
> updated soon) that we use for all our data processing. It is set to
> PRIVATE with an access list of our lab members. Up until this
> afternoon, all had been able to login without problem. However, for
> one user, call her user1, she has not been able to ssh into server1
> starting early this afternoon. She is, however, able to ssh into all
> of our other lab machines and work stations, as well as any other
> Athena machine. In addition, all other lab users (on the access list
> for server1) are able to login to server1. This occurs no matter
> where the user is logged in from (i.e., also from external hosts),
> when we destroy credentials (using kdestroy), when we have the user
> logout of her workstation and then logged back in, and so on.
>
> The symptoms of the problem are as follows: when user1 tries to login
> to server1, we get the following:
>
> workstation% ssh user1@server1
>
> workstation%
>
> i.e., no error messages. The corresponding entry in /var/log/messages
> is:
>
> Jan 24 16:16:39 server1 sshd[995]: fatal: Timeout before
> authentication for [workstation IP].
>
> However, as stated previously, this does not happen for any other user
> on the access list for server1.
>
> I have had this user try to connect to server1 while turning on
> debugging, both on the client and the server side. Those outputs are
> included at the end of this e-mail.
>
> So, to recap: user1 is not able to login to server1. user1 is able to
> login to any other athena machine. All other lab users on the access
> list are able to login to server1.
>
> As you can bet, this is *extremely* disabling for this particular
> user, and any help would be *greatly* appreciated.
>
> Thanks,
>
> Nick Knouf
> Lab Manager, Kanwisher Lab
>
>
> CLIENT SIDE SSH messages
>
> workstation% ssh user1@server1 -v
> OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090600f
> debug1: Reading configuration data /etc/ssh_config
> debug1: Seeding random number generator
> debug1: Rhosts Authentication disabled, originating port will not be
> trusted.
> debug1: restore_uid
> debug1: ssh_connect: getuid 5464 geteuid 5464 anon 1
> debug1: Connecting to server1 [server1 IP] port 22.
> debug1: temporarily_use_uid: 5464/101 (e=5464)
> debug1: restore_uid
> debug1: temporarily_use_uid: 5464/101 (e=5464)
> debug1: restore_uid
> debug1: Connection established.
> debug1: identity file /mit/user1/.ssh/identity type -1
> debug1: identity file /mit/user1/.ssh/id_rsa type -1
> debug1: identity file /mit/user1/.ssh/id_dsa type -1
> debug1: Remote protocol version 1.99, remote software version
> OpenSSH_3.0.2p1
> debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_3.0.2p1
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: dh_gen_key: priv key bits set: 121/256
> debug1: bits set: 500/1024
> debug1: Calling gss_init_sec_context
> debug1: Delegating credentials
> debug1: Received GSSAPI_COMPLETE
> debug1: Calling gss_init_sec_context
> debug1: Delegating credentials
> debug1: bits set: 505/1024
> debug1: kex_derive_keys
> debug1: newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: waiting for SSH2_MSG_NEWKEYS
> debug1: newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: done: ssh_kex2.
> debug1: send SSH2_MSG_SERVICE_REQUEST
> debug1: service_accept: ssh-userauth
> debug1: got SSH2_MSG_SERVICE_ACCEPT
>
>
> SERVER SIDE SSHD messages
>
> bash-2.05a# /etc/athena/sshd -d
> debug1: Seeding random number generator
> debug1: sshd version OpenSSH_3.0.2p1
> debug1: private host key: #0 type 0 RSA1
> debug1: read PEM private key done: type RSA
> debug1: private host key: #1 type 1 RSA
> debug1: read PEM private key done: type DSA
> debug1: private host key: #2 type 2 DSA
> socket: Address family not supported by protocol
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
> Generating 768 bit RSA key.
> RSA key generation complete.
> debug1: Server will not fork when running in debugging mode.
> Connection from workstation port 34297
> debug1: Client protocol version 2.0; client software version
> OpenSSH_3.0.2p1
> debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
> Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-1.99-OpenSSH_3.0.2p1
> debug1: Rhosts Authentication disabled, originating port 34297 not
> trusted.
> debug1: list_hostkey_types: ssh-rsa,ssh-dss
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: Wait SSH2_MSG_GSSAPI_INIT
> debug1: Received some client credentials
> debug1: gss_complete
> debug1: dh_gen_key: priv key bits set: 126/256
> debug1: bits set: 482/1024
> debug1: bits set: 519/1024
> debug1: kex_derive_keys
> debug1: newkeys: mode 1
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: waiting for SSH2_MSG_NEWKEYS
> debug1: newkeys: mode 0
> debug1: SSH2_MSG_NEWKEYS received
> debug1: KEX done
> debug1: userauth-request for user user1 service ssh-connection method
> none
> debug1: attempt 0 failures 0
>
