openssh bugs - May 2007 - [Bug 1273] Interactive mode detection should not be predicated on pty allocation

http://bugzilla.mindrot.org/show_bug.cgi?id=1273


Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX
                 CC|                            |djm at mindrot.org




--- Comment #1 from Damien Miller <djm at mindrot.org>  2007-05-17
16:06:57 ---
It is possible to have interactive sessions that have commands, e.g.
"ssh -t somehost vi somefile" so basing the interactivity check on
command length is incorrect. 

I don't see any better way of determining user intent to interact with
a remote program than whether or not a TTY is requested so I am closing
the bug. If you can think of one, feel free to reopen it.

By the way, if it is just the "connection closed" message that annoys
you, you can silence it using "ssh -q" or a LogLevel entry in the
client config.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.mindrot.org/show_bug.cgi?id=1273


John Caruso <jcaruso at arenasolutions.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jcaruso at arenasolutions.com




--- Comment #2 from John Caruso <jcaruso at arenasolutions.com> 
2007-05-18 03:21:23 ---
Yes, it was the "Connection to <host> closed" message that
prompted me
to look into this, and it does strike me as a genuine (though clearly
not very important) bug.  For example, this should print the message
but doesn't:

% ssh -T user at my.host
user at my.host's password:
ls
myfile1
myfile2
uname -r
2.6.9-55.ELsmp
exit

And this should not print the message but does:

% ssh -t user at my.host "ls; uname -r"
user at my.host's password:
myfile1   myfile2
2.6.9-55.ELsmp
Connection to my.host closed.

And it doesn't make sense that this prints the message when the first
example doesn't:

% ssh -t user at my.host
user at my.host's password:
**** Welcome to my.host ****
$ ls
myfile1   myfile2
$ uname -r
2.6.9-55.ELsmp
$ exit
Connection to my.host closed.

It seems to me that the purpose of "Connection to <host> closed"
is to
inform the user that after some variable number of commands and
responses, their session is now over.  If they specified a remote
command--even if it was passwd, or vi, or anything else that requires
some interaction--they already know that the connection is going to
close when the command that they specified has finished, and so they
don't need the message.

If you agree with that, I'd say that checking buffer_len(&command)==0
(or some equivalent, if that's not available in client_loop)--rather
than checking have_pty--is exactly the right solution.  I know the
message can be suppressed by setting the log level, but that's a
kludge, not a fix, and highly undesirable since it may suppress
important info.

Anyway, it's certainly your call if you want to stick with WONTFIX--I
just wanted to explain a bit more completely why I considered it a
(minor) bug.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.mindrot.org/show_bug.cgi?id=1273





--- Comment #3 from Damien Miller <djm at mindrot.org>  2007-05-18
07:07:30 ---
Sure, the "connection closed" message is arguably redundant in cases
where the connection was closed because of user interaction, but the
user may not have been expecting the connection to close.

For example:

# ssh -t user at somehost sudo -s
--- welcome to somehost ---
# do something
#
Connection to somehost closed
#

The message is pretty important in this case if the close is
unexpected, especially if the next command is "reboot" :)

Again, I think Loglevel=quiet is the right answer for you - it
suppresses only informational messages, warnings and errors are still
displayed.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

http://bugzilla.mindrot.org/show_bug.cgi?id=1273





--- Comment #4 from John Caruso <jcaruso at arenasolutions.com> 
2007-05-18 11:25:27 ---
Maybe I'm not being clear.  I'm not saying that "Connection to
<host>
closed" is redundant if it's caused by user interaction.  I'm
saying
that I always took "Connection closed" to mean: you started a session
that involved a variable number of commands, and now that session is
done.  But in the code as it stands now "Connection closed" actually
means: you had a tty, and now you're done.  I don't think it's that
useful for SSH to tell you that you had a tty, but I do think it's
useful for SSH to tell you that your variable-length session is now
finished.

The ssh -T (with no remote command) example really illustrates the
difference.  It definitely seems to me that it should print the
"Connection closed" message, but the current code won't do that. 
And
that's part of the bug that's not helped by the ssh -q/LogLevel
workaround--in fact there's no way to get the "Connection closed"
message with ssh -T, whether you're doing a truly interactive session,
vi, passwd, sudo -s, or anything else.

Note that I'm NOT just trying to get rid of the "Connection
closed"
message...in fact I'm specifically saying I think it should occur in
one context where it currently doesn't, in addition to not occurring in
one context where it currently does.

Anyway, I'm ok with WONTFIX even though I do think this is a bug.  I
just wanted to explain it a bit more since it doesn't seem like my
meaning was getting through.


-- 
Configure bugmail: http://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.