One machine or the other could be blocking ports above 1024, which ssh also needs to complete the connection. Check firewall logs on the server, and make sure that logging is turned on for anything that's not accepted, at least while you're debugging.
If this is the only server where the problem shows up, and several clients see it, then you might try a clean install of openssh and openssl on the server, after removing /etc/ssh. On Sun, Dec 09, 2001 at 12:24:57PM +0200, 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, > > -- > Oleg Goldshmidt | [EMAIL PROTECTED] > "If it ain't broken, it has not got enough features yet." > > > > _______________________________________________ > Seawolf-list mailing list > [EMAIL PROTECTED] > https://listman.redhat.com/mailman/listinfo/seawolf-list -- Jan Carlson janc at kubwa dot com _______________________________________________ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
