Re: ssh closing down connection immediately
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
Re: ssh closing down connection immediately
Taylor, ForrestX [EMAIL PROTECTED] writes: Did you use ssh -v -v -v? Did you check /var/log/secure? /var/log/secure only says Dec 11 12:10:39 server sshd[10325]: Accepted publickey for oleg from 192.168.0.7 port 37287 ssh2 I posted ssh -v output earlier, here is the tail of the output from ssh -v -v -v, starting from successful authentication. I will be very grateful if anyone can help me make heads or tails here: == start of ssh -v -v -v output = debug1: ssh-userauth2 successful: method publickey debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug2: tty_make_modes: ospeed 38400 debug2: tty_make_modes: ispeed 38400 debug2: tty_make_modes: 1 3 debug2: tty_make_modes: 2 28 debug2: tty_make_modes: 3 127 debug2: tty_make_modes: 4 21 debug2: tty_make_modes: 5 4 debug2: tty_make_modes: 6 0 debug2: tty_make_modes: 7 0 debug2: tty_make_modes: 8 17 debug2: tty_make_modes: 9 19 debug2: tty_make_modes: 10 26 debug2: tty_make_modes: 12 18 debug2: tty_make_modes: 13 23 debug2: tty_make_modes: 14 22 debug2: tty_make_modes: 18 15 debug2: tty_make_modes: 30 0 debug2: tty_make_modes: 31 0 debug2: tty_make_modes: 32 0 debug2: tty_make_modes: 33 0 debug2: tty_make_modes: 34 0 debug2: tty_make_modes: 35 0 debug2: tty_make_modes: 36 1 debug2: tty_make_modes: 37 0 debug2: tty_make_modes: 38 1 debug2: tty_make_modes: 39 0 debug2: tty_make_modes: 40 0 debug2: tty_make_modes: 41 0 debug2: tty_make_modes: 50 1 debug2: tty_make_modes: 51 1 debug2: tty_make_modes: 52 0 debug2: tty_make_modes: 53 1 debug2: tty_make_modes: 54 1 debug2: tty_make_modes: 55 1 debug2: tty_make_modes: 56 0 debug2: tty_make_modes: 57 0 debug2: tty_make_modes: 58 0 debug2: tty_make_modes: 59 1 debug2: tty_make_modes: 60 1 debug2: tty_make_modes: 61 1 debug2: tty_make_modes: 62 0 debug2: tty_make_modes: 70 1 debug2: tty_make_modes: 71 0 debug2: tty_make_modes: 72 1 debug2: tty_make_modes: 73 0 debug2: tty_make_modes: 74 0 debug2: tty_make_modes: 75 0 debug2: tty_make_modes: 90 1 debug2: tty_make_modes: 91 1 debug2: tty_make_modes: 92 0 debug2: tty_make_modes: 93 0 debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: shell debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 16384 debug2: channel 0: rcvd adjust 32768 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 debug2: channel 0: no data after CLOSE Last login: Tue Dec 11 12:10:07 2001 from client debug2: channel 0: no data after CLOSE 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.1 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 295.9 debug1: Exit status 254 === end of ssh -v -v -v output = Subsystem sftp/usr/libexec/openssh/sftp-server Did you check that this file exists on both machines? What does `rpm -V openssh-server` show? On both machines: -rwxr-xr-x1 root root23484 Dec 3 22:18 /usr/libexec/openssh/sftp-server On the server: # rpm -V openssh-server S.5T c /etc/ssh/sshd_config - which is what I expect - I edited the file, and posted it here. -- 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
Another arbitrary guess. Does the remote user have a valid shell? ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Re: ssh closing down connection immediately
On 11 Dec 2001, Oleg Goldshmidt wrote: Keith Morse [EMAIL PROTECTED] writes: Another arbitrary guess. Does the remote user have a valid shell? # grep oleg /etc/passwd oleg:x:500:500:Oleg Goldshmidt:/home/oleg:/bin/bash # /bin/bash --version GNU bash, version 2.04.21(1)-release (i386-redhat-linux-gnu) Copyright 1999 Free Software Foundation, Inc. Egad, Oleg. You may forced to sacrifice these systems to the Gods of Binary and Silicon. For your comparision also, a tail of a ssh -v -v -v remotehost with dsa key. Yours continues at the line: debug1: channel 0: open confirm rwindow 0 rmax 32768 where mine just dumps to the shell. Maybe its time to go talk to the openssh developers? --- debug1: ssh-userauth2 successful: method publickey debug3: clear hostkey 0 debug3: clear hostkey 1 debug3: clear hostkey 2 debug1: channel 0: new [client-session] debug1: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: client_init id 0 arg 0 debug2: tty_make_modes: ospeed 38400 debug2: tty_make_modes: ispeed 38400 debug2: tty_make_modes: 1 3 debug2: tty_make_modes: 2 28 debug2: tty_make_modes: 3 127 debug2: tty_make_modes: 4 21 debug2: tty_make_modes: 5 4 debug2: tty_make_modes: 6 0 debug2: tty_make_modes: 7 0 debug2: tty_make_modes: 8 17 debug2: tty_make_modes: 9 19 debug2: tty_make_modes: 10 26 debug2: tty_make_modes: 12 18 debug2: tty_make_modes: 13 23 debug2: tty_make_modes: 14 22 debug2: tty_make_modes: 18 15 debug2: tty_make_modes: 30 0 debug2: tty_make_modes: 31 0 debug2: tty_make_modes: 32 0 debug2: tty_make_modes: 33 0 debug2: tty_make_modes: 34 0 debug2: tty_make_modes: 35 0 debug2: tty_make_modes: 36 1 debug2: tty_make_modes: 37 0 debug2: tty_make_modes: 38 1 debug2: tty_make_modes: 39 0 debug2: tty_make_modes: 40 0 debug2: tty_make_modes: 41 0 debug2: tty_make_modes: 50 1 debug2: tty_make_modes: 51 1 debug2: tty_make_modes: 52 0 debug2: tty_make_modes: 53 1 debug2: tty_make_modes: 54 1 debug2: tty_make_modes: 55 1 debug2: tty_make_modes: 56 0 debug2: tty_make_modes: 57 0 debug2: tty_make_modes: 58 0 debug2: tty_make_modes: 59 1 debug2: tty_make_modes: 60 1 debug2: tty_make_modes: 61 1 debug2: tty_make_modes: 62 0 debug2: tty_make_modes: 70 1 debug2: tty_make_modes: 71 0 debug2: tty_make_modes: 72 1 debug2: tty_make_modes: 73 0 debug2: tty_make_modes: 74 0 debug2: tty_make_modes: 75 0 debug2: tty_make_modes: 90 1 debug2: tty_make_modes: 91 1 debug2: tty_make_modes: 92 0 debug2: tty_make_modes: 93 0 debug1: Requesting X11 forwarding with authentication spoofing. debug1: channel request 0: shell debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 16384 Last login: Wed Dec 11 11:50:54 2024 from remotehost.domainname.com sh: /usr/X11R6/bin/xauth: No such file or directory ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Re: ssh closing down connection immediately
Jack Bowling [EMAIL PROTECTED] writes: 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. Thanks, Jack, but it didn't help, either: I added ALL:192.168. to /etc/hosts.allow on the server, restarted sshd for good measure, but nothing has changed. Besides, why that particular server? Baffling. -- 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
Hi Oleg, On 10 Dec 2001, Oleg Goldshmidt wrote: Jack Bowling [EMAIL PROTECTED] writes: 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. Thanks, Jack, but it didn't help, either: I added ALL:192.168. to /etc/hosts.allow on the server, restarted sshd for good measure, but nothing has changed. Besides, why that particular server? Baffling. Did you /etc/ssh/sshd_config have a : AllowUsers put_your_login_here ? :) Just a thought. Good luck. K_K -- 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
Try to disable X-forwarding (ssh -x) or if it dont work try the verbose mode (ssh -v) to see where it fails.. Dams You wrote : On 10 Dec 2001, Oleg Goldshmidt wrote: Jack Bowling [EMAIL PROTECTED] writes: 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. Thanks, Jack, but it didn't help, either: I added ALL:192.168. to /etc/hosts.allow on the server, restarted sshd for good measure, but nothing has changed. Besides, why that particular server? Baffling. Did you /etc/ssh/sshd_config have a : AllowUsers put_your_login_here ? :) Just a thought. -- Dams Nadé ActiVia Networks : http://www.activia.net/ Association AMIN : http://amin.unice.fr/ ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
Re: ssh closing down connection immediately
King_Kong [EMAIL PROTECTED] writes: Did you /etc/ssh/sshd_config have a : AllowUsers put_your_login_here ? :) No ;-) -- 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
Dams [EMAIL PROTECTED] writes: Try to disable X-forwarding (ssh -x) No difference (and it shouldn't matter) or if it dont work try the verbose mode (ssh -v) to see where it fails.. I included ssh -v output with my original posting. -- 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
On 10 Dec 2001, Oleg Goldshmidt wrote: King_Kong [EMAIL PROTECTED] writes: Did you /etc/ssh/sshd_config have a : AllowUsers put_your_login_here ? :) No ;-) Hey Oleg, wanna try it out...? I've used to be the same situation before. :) K_K -- 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
King_Kong [EMAIL PROTECTED] writes: AllowUsers put_your_login_here Hey Oleg, wanna try it out...? I've used to be the same situation before. Oh, but I did... And I don't understand why it should help - by default everybody is allowed (at least according to man sshd), so listing users explicitly will not improve anybody's chances... -- 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
Just in case it might help, here is the (not commented part of) /etc/ssh/sshd_config on the problematic server: Port 22 HostKey /etc/ssh/ssh_host_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key ServerKeyBits 768 LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes IgnoreRhosts yes StrictModes yes PrintMotd yes KeepAlive yes SyslogFacility AUTHPRIV LogLevel INFO RhostsAuthentication no RhostsRSAAuthentication no HostbasedAuthentication no RSAAuthentication yes PasswordAuthentication yes PermitEmptyPasswords no Subsystem sftp/usr/libexec/openssh/sftp-server -- 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
On 10 Dec 2001, Oleg Goldshmidt wrote: Just in case it might help, here is the (not commented part of) /etc/ssh/sshd_config on the problematic server: You've certainly got my interest now. The parameters in sshd_config you posted appear to match my stock one on RH7.2 box (sans commented lines). Looking at your dump (ssh -v) from a previous message, I noticed that the session appears to be authenticating via RSA. I'm also guessing you use ssh-agent as the auth method was public key. So based on that You might try the ssh -v -v -v host and post it's dump to the list. and you might try deleting the RSA key pair and generating a new one and push the public key back to the server. even better generate a DSA key pair and push it's public key to the server. ___ Seawolf-list mailing list [EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/seawolf-list
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
