ssh closing down connection immediately
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- anywherevernonany - 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,
Re: ssh closing down connection immediately
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
Re: ssh closing down connection immediately
Jan Carlson [EMAIL PROTECTED] writes: One machine or the other could be blocking ports above 1024, which ssh also needs to complete the connection. No, that's not the case. And remember that I can ssh as root - I think ssh needs non-reserved ports in that case as well. 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. Did that, too - no dice. It is clear that a connection is established, and then closed immediately. $ ssh oleg@server Last login: Sun Dec 9 18:49:20 2001 from client Connection to server closed. The last login comes from the server machine, meaning that I have successfully authenticated myself. Then something happens... -- 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
Re: ssh closing down connection immediately
** Reply to message from Oleg Goldshmidt [EMAIL PROTECTED] on 09 Dec 2001 12:24:57 +0200 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. snip Oleg, I just went through this on 7.2. In my case, I had to add the client IP to /etc/hosts.allow since RH compiles ssh with libwrap. Check yours out. jb ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Upgrading Seawolf
Hello listmembers, today I purchased a linux magazine including 2 CD with the new Red Hat 7.2 (Enigma),I confess that I'm tempted to upgrade my current 7.1 but wonder ask if can I expect some troubles or malfunctions (e.g. ext3 fs,gnome...) I think that upgrade will install Nautilus as the new file manager,a thing that I would like to keep off the system now... What can you say about this? Many Thanks. -- Regards,Marco [EMAIL PROTECTED] | GSM:+393297378262 AX25:[EMAIL PROTECTED] | AMPRNET:[EMAIL PROTECTED] gpg key available on http://www.qsl.net/ik5bcu Red Hat Linux release 7.1 (Seawolf) kernel 2.4.3-12 Uptime 7:43pm up 2:30, 2 users, load average: 0.00, 0.02, 0.00 ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Re: Upgrading Seawolf
I upgraded from 7.1 to 7.2 without any problems, and if i remember right they gave you the option in the upgrade as to weather you wanted to upgrade to the nautilus file manager or not. Keith Marco Calistri wrote: Hello listmembers, today I purchased a linux magazine including 2 CD with the new Red Hat 7.2 (Enigma),I confess that I'm tempted to upgrade my current 7.1 but wonder ask if can I expect some troubles or malfunctions (e.g. ext3 fs,gnome...) I think that upgrade will install Nautilus as the new file manager,a thing that I would like to keep off the system now... What can you say about this? Many Thanks. -- Keith Jonathan Bodwell -- Computer Engineering Student -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- http://www.keithbodwell.com -- 303 Notch Hill Rd. North Branford, CT 06471 (203) 481-9925 ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Re: Upgrading Seawolf
On Sun, Dec 09, 2001 at 11:04:59PM +0100, Marco Calistri wrote: Hello listmembers, today I purchased a linux magazine including 2 CD with the new Red Hat 7.2 (Enigma),I confess that I'm tempted to upgrade my current 7.1 but wonder ask if can I expect some troubles or malfunctions (e.g. ext3 fs,gnome...) I think that upgrade will install Nautilus as the new file manager,a thing that I would like to keep off the system now... What can you say about this? Many Thanks. -- I haven't seen this anywhere eslse but I found that the gnome configuration files in every home directory under 7.1 (if you are runnig gnome) are not compatiple with 7.2. I had to recreate the configuration files in each directory by removing the .gnome* files and allowing them to be recreated upon logging in again. Otherwise the upgrade went well. -- --- Aaron Konstam Computer Science Trinity University 715 Stadium Dr. San Antonio, TX 78212-7200 telephone: (210)-999-7484 email:[EMAIL PROTECTED] ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
