Check that /etc/pam.d/sshd on the server does not have any errors. Make certain that $HOME/.ssh has perms set to 700.
If these are OK (they probably are) then stop sshd on the problem server and restart it in debug mode. # service sshd stop # sshd -d Try logging in and see what the server reports. On 9 Dec 2001, Oleg Goldshmidt wrote: - - I suddennly cannot ssh as user to one of our RH7.1 machines. I used to - be able to... I can ssh as root without a problem, but no ordinary - user can connect, either using RSA or DSA keys, or ssh 1, or just with - a password. This happens for several clients. The clients are able to - connect to other servers without a problem. - - I tried to downgrade openssh on the server (to 2.9p2-10.7, then to - 2.9p2-8.7), to no avail. - - Here is one configuration I am trying to debug: - - Client [192.168.0.7]: - - Linux 2.4.9-12 i686 unknown - openssh-2.9p2-11.7 - openssh-server-2.9p2-11.7 - openssh-askpass-2.9p2-11.7 - openssh-clients-2.9p2-11.7 - openssh-askpass-gnome-2.9p2-11.7 - - Server [192.168.0.8]: - - Linux 2.4.2-2 i686 unknown - openssh-askpass-2.9p2-11.7 - openssh-clients-2.9p2-11.7 - openssh-2.9p2-11.7 - openssh-askpass-gnome-2.9p2-11.7 - openssh-server-2.9p2-11.7 - - I am looking at the ssh -v log, and it seems to me that the connection is - established and then immediately closed. - - OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f - debug1: Reading configuration data /etc/ssh/ssh_config - debug1: Applying options for * - debug1: Seeding random number generator - debug1: Rhosts Authentication disabled, originating port will not be trusted. - debug1: restore_uid - debug1: ssh_connect: getuid 500 geteuid 0 anon 1 - debug1: Connecting to <server> [192.168.0.8] port 22. - debug1: temporarily_use_uid: 500/100 (e=0) - debug1: restore_uid - debug1: temporarily_use_uid: 500/100 (e=0) - debug1: restore_uid - debug1: Connection established. - debug1: read PEM private key done: type DSA - debug1: read PEM private key done: type RSA - debug1: identity file /home/oleg/.ssh/identity type 0 - debug1: identity file /home/oleg/.ssh/id_rsa type 1 - debug1: identity file /home/oleg/.ssh/id_dsa type 2 - debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 - debug1: match: OpenSSH_2.9p2 pat ^OpenSSH - Enabling compatibility mode for protocol 2.0 - debug1: Local version string SSH-2.0-OpenSSH_2.9p2 - 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: SSH2_MSG_KEX_DH_GEX_REQUEST sent - debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP - debug1: dh_gen_key: priv key bits set: 119/256 - debug1: bits set: 1002/2049 - debug1: SSH2_MSG_KEX_DH_GEX_INIT sent - debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY - debug1: Host '<server>' is known and matches the RSA host key. - debug1: Found key in /home/oleg/.ssh/known_hosts2:4 - debug1: bits set: 1018/2049 - debug1: ssh_rsa_verify: signature correct - 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 - debug1: authentications that can continue: publickey,password - debug1: next auth method to try is publickey - debug1: try pubkey: /home/oleg/.ssh/id_rsa - debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x80889e8 hint 1 - debug1: read PEM private key done: type RSA - debug1: ssh-userauth2 successful: method publickey - debug1: fd 6 setting O_NONBLOCK - debug1: channel 0: new [client-session] - debug1: channel_new: 0 - debug1: send channel open 0 - debug1: Entering interactive session. - debug1: client_init id 0 arg 0 - debug1: Requesting X11 forwarding with authentication spoofing. - debug1: channel request 0: shell - debug1: channel 0: open confirm rwindow 0 rmax 16384 - debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 - debug1: channel 0: rcvd eof - debug1: channel 0: output open -> drain - debug1: channel 0: rcvd close - debug1: channel 0: input open -> closed - debug1: channel 0: close_read - debug1: channel 0: obuf empty - debug1: channel 0: output drain -> closed - debug1: channel 0: close_write - debug1: channel 0: send close - debug1: channel 0: is dead - debug1: channel_free: channel 0: status: The following connections are open: - #0 client-session (t4 r0 i8/0 o128/0 fd -1/-1) - - debug1: channel_free: channel 0: dettaching channel user - Connection to <server> closed. - debug1: Transferred: stdin 0, stdout 0, stderr 30 bytes in 0.0 seconds - debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 1165.0 - debug1: Exit status 254 - - The server's /var/log/messages have an open/close pair of entries - indeed. - - Dec 9 12:17:25 <server> sshd(pam_unix)[8166]: session opened for user oleg by (uid=0) - Dec 9 12:17:25 <server> sshd(pam_unix)[8166]: session closed for user oleg - - There is no firewall I know of between the client and the server. On - server, I have - - # ipchains -L - Chain input (policy ACCEPT): - target prot opt source destination ports - DENY tcp ----l- anywhere vernon any -> http - Chain forward (policy ACCEPT): - Chain output (policy ACCEPT): - - (vernon is a machine that has nothing to do with the ssh session - - it's on a different subnet altogether). - - On server, sshd is running, port 22 is open, etc, etc. - - Any clues? Thanks, - - -- -- Stephen Carville http://www.heronforge.net/~stephen/gnupgkey.txt ============================================================== Government is like burning witches: After years of burning young women failed to solve any of society's problems, the solution was to burn more young women. ============================================================== _______________________________________________ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
