openssh unix dev - May 2001 - bug report

On Wed, May 23, 2001 at 10:49:54PM -0400, mugz wrote:
> 
> I'm always a bit slow to report bugs i see, figuing someone else will
> report it and that it will eventually get fixed. This one has been
> somewhat of a problem for a while now. I run Linux Slackware -current and
> just upgraded to OpenSSH 2.9p1, but I have noticed this same bug on every
> platform and OS running OpenSSH.
> 
> If a user logs in and starts any kind of background process such as
> "screen" "bnc" "mud" "eggdrop" etc,
the console "hangs" when they log out.
> When I ssh to a shell running OpenSSH from work or from home, start a
> screen or a bnc and then exit with that process running, I have to go to
> another console and manually kill my connection locally. If i then log
> back into the same shell and type: last -5 myuserid, it shows me as
> "still logged in" from that previous session. You can test this
easily by
> logging in using ssh and typing:
> 
> sleep 200 &
> exit
does
	sleep 1234 < /dev/null > /dev/null 2>&
	exit
work?

Markus Friedl <markus.friedl at informatik.uni-erlangen.de> writes:
> On Wed, May 23, 2001 at 10:49:54PM -0400, mugz wrote:
> > 
> > I'm always a bit slow to report bugs i see, figuing someone else
will
> > report it and that it will eventually get fixed. This one has been
> > somewhat of a problem for a while now. I run Linux Slackware -current
and
> > just upgraded to OpenSSH 2.9p1, but I have noticed this same bug on
every
> > platform and OS running OpenSSH.
> > 
> > If a user logs in and starts any kind of background process such as
> > "screen" "bnc" "mud" "eggdrop"
etc, the console "hangs" when they log out.
> > When I ssh to a shell running OpenSSH from work or from home, start a
> > screen or a bnc and then exit with that process running, I have to go
to
> > another console and manually kill my connection locally. If i then log
> > back into the same shell and type: last -5 myuserid, it shows me as
> > "still logged in" from that previous session. You can test
this easily by
> > logging in using ssh and typing:
> > 
> > sleep 200 &
> > exit
> 
> does
> 	sleep 1234 < /dev/null > /dev/null 2>&
> 	exit
> work?
You can make init the parent of the remote shell executing mud or
whatever.  This uses a subshell to launch the command (parentheses do
this in Bourne-type shell like bash), so when the subshell exits, init
inherits the sleep process:

  here$ ssh there
  there$ (sleep 1234 &)
  there$ exit
  here$

... leaving you free to logout without anything blocking.

-- 
--Ed Cashin                   PGP public key:
  ecashin at terry.uga.edu       http://www.terry.uga.edu/~ecashin/pgp/

I tracked this one down. I am running OpenSSH_2.9p1 and if a user logs in
whith securecrt and uses the "disconect" button to disconnect from the
shell I get this error in the log:

Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel: kill
16131: Operation not permitted
Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel: kill
16131: Operation not permitted

Also, when I type:

last -30 | grep still

It shows them as still logged in, even though they have long sense
disconnected. This error does not occur if they use "exit" to exit the
shell, also I do not see this same error in PuTTY.

mugz

can you start
	$ sshd -d -d -d -p 1234
and connect to port 1234 with securecrt?

the traces could be of use to us.


On Fri, Jun 01, 2001 at 02:09:57AM -0400, mugz wrote:
> 
> I tracked this one down. I am running OpenSSH_2.9p1 and if a user logs in
> whith securecrt and uses the "disconect" button to disconnect
from the
> shell I get this error in the log:
> 
> Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel: kill
> 16131: Operation not permitted
> Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel: kill
> 16131: Operation not permitted
> 
> Also, when I type:
> 
> last -30 | grep still
> 
> It shows them as still logged in, even though they have long sense
> disconnected. This error does not occur if they use "exit" to
exit the
> shell, also I do not see this same error in PuTTY.
> 
> mugz
> 
>

OK, I know some mailing lists dont like attachments, so I did as you asked
and have pasted the log to the end of this message. It is the log of a
user logging in with secureCRT and using the "disconnect" button to
exit
the shell:

On Sat, 2 Jun 2001, Markus Friedl wrote:
> can you start
> 	$ sshd -d -d -d -p 1234
> and connect to port 1234 with securecrt?
>
> the traces could be of use to us.
>
>
> On Fri, Jun 01, 2001 at 02:09:57AM -0400, mugz wrote:
> >
> > I tracked this one down. I am running OpenSSH_2.9p1 and if a user logs
in
> > whith securecrt and uses the "disconect" button to
disconnect from the
> > shell I get this error in the log:
> >
> > Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel:
kill
> > 16131: Operation not permitted
> > Jun  1 01:47:35 members sshd[16130]: error: session_close_by_channel:
kill
> > 16131: Operation not permitted
> >
> > Also, when I type:
> >
> > last -30 | grep still
> >
> > It shows them as still logged in, even though they have long sense
> > disconnected. This error does not occur if they use "exit"
to exit the
> > shell, also I do not see this same error in PuTTY.
> >
> > mugz
> >
> >
>
debug1: Seeding random number generator
debug1: sshd version OpenSSH_2.9p1
debug1: private host key: #0 type 0 RSA1
debug3: No RSA1 key file /etc/ssh/ssh_host_rsa_key.
debug1: read PEM private key done: type RSA
debug1: private host key: #1 type 1 RSA
debug3: No RSA1 key file /etc/ssh/ssh_host_dsa_key.
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 1234 on 0.0.0.0.
Server listening on 0.0.0.0 port 1234.
debug1: Server will not fork when running in debugging mode.
Connection from 137.79.89.118 port 1330
debug1: Client protocol version 2.0; client software version 3.0 SecureCRT (tm),
a product of Van Dyke Technologies, Inc.
debug1: match: 3.0 SecureCRT (tm), a product of Van Dyke Technologies, Inc. pat
^3\.0 SecureCRT
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_2.9p1
debug1: Rhosts Authentication disabled, originating port not trusted.
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc
at lysator.liu.se
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc
at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at
openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: 3des-cbc
debug2: kex_parse_kexinit: hmac-md5
debug2: kex_parse_kexinit: hmac-md5
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: server_init_dispatch_20
debug1: server_input_channel_open: ctype session rchan 0 win 8192 max 8192
debug1: input_session_request
debug1: channel 0: new [server-session]
debug1: session_new: init
debug1: session_new: session 0
debug1: session_open: channel 0
debug1: session_open: session 0: link with channel 0
debug1: server_input_channel_open: confirm session
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request pty-req reply 0
debug1: session_pty_req: session 0 alloc /dev/pts/2
debug2: tty_parse_modes: SSH2 n_bytes 46
debug2: tty_parse_modes: 1 3
debug2: tty_parse_modes: 5 4
debug2: tty_parse_modes: 4 21
debug2: tty_parse_modes: 8 17
debug2: tty_parse_modes: 9 19
debug2: tty_parse_modes: 10 26
debug2: tty_parse_modes: 12 18
debug2: tty_parse_modes: 13 23
debug2: tty_parse_modes: 14 22
debug2: callback done
debug2: callback start
debug1: session_by_channel: session 0 channel 0
debug1: session_input_channel_req: session 0 channel 0 request shell reply 0
debug1: channel 0: rfd 7 isatty
debug1: fd 7 setting O_NONBLOCK
debug1: fd 3 IS O_NONBLOCK
debug2: callback done
debug1: Setting controlling tty using TIOCSCTTY.
debug1: channel 0: rcvd close
debug1: channel 0: output open -> drain
debug1: channel 0: input open -> closed
debug1: channel 0: close_read
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 server-session (t4 r0 i8/0 o128/0 fd -1/-1)

debug1: channel_free: channel 0: dettaching channel user
debug1: session_by_channel: session 0 channel 0
debug1: session_close_by_channel: channel 0 kill 11786
debug1: Received SIGCHLD.
debug3: tvp!=NULL kid 1 mili 100
debug1: session_by_pid: pid 11786
debug1: session_pty_cleanup: session 0 release /dev/pts/2
debug1: session_free: session 0 pid 11786
Connection closed by remote host.
Closing connection to 137.79.89.118