When you ssh to a host specifying a command but no -t it shows only the command output: $ ssh myhost date me@myhost's password: Thu Jan 4 19:25:11 PST 2007 $ But if you specify -t (to allocate a pseudo-TTY) along with a command, it erroneously prints a "Connection to <hostname> closed" message after the command output: $ ssh -t myhost date me@myhost's password: Thu Jan 4 19:25:16 PST 2007 Connection to myhost closed. $ In looking through the code, this is happening because the determination of whether or not we're in "interactive mode" is closely associated with whether or not a pty is being allocated. However, the -T/-t options make it possible both to 1) have an interactive session without a pty and 2) have a non-interactive session with a pty. Though I can't think of a use for the first, the second is quite useful if the remote command is something that prompts the user (e.g. passwd). The printing of the "Connection to <host> closed." message should be be predicated on whether or not the session is truly interactive (perhaps using a test of buffer_len(&command)==0 as is used elsewhere in ssh.c), and not on the allocation of a pty. My only real concern here is the "Connection to <host> closed." message, though; if that can be fixed to happen only on truly interactive sessions, I'd be happy.
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.
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@my.host user@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@my.host "ls; uname -r" user@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@my.host user@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.
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@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.
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.
Close resolved bugs after release.
(In reply to comment #3) > 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@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" :) Ideally people have something useful in their $PS1 rather than just "#". And if they don't, they deserve to reboot their operational machines at the wrong time. > Again, I think Loglevel=quiet is the right answer for you - it > suppresses only informational messages, warnings and errors are still > displayed. Please be aware that the workaround for this bug is not suitable. For instance, "ssh -o Loglevel=quiet -t" to a host with a changed hostkeys results in an error code of 255 and absolutely no messages at all, instead of the hint: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! ... That in itself is probably a bug, in that the warning message is being logged at the same level as something as informational as "connection closed" (seriously? "connection to blah closed" is logged at a "fatal" level instead of just "info", according to my testing a moment ago?). But this would be a lot more acceptable if I didn't have to supply "-o Loglevel=quiet" just to avoid a silly redundant message printed out at the end of my non-interactive session that nevertheless needed a tty allocated. Please consider reopening this bug.