openssh bugs - Jul 2017 - [Bug 2743] New: ssh with -T hangs putty

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

            Bug ID: 2743
           Summary: ssh with -T hangs putty
           Product: Portable OpenSSH
           Version: 7.5p1
          Hardware: Other
                OS: Other
            Status: NEW
          Severity: major
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: bagajjal at microsoft.com

Created attachment 3014
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3014&action=edit
putty logs

Hi,

I am trying to run a putty SSH session with -T option, the terminal
gets stuck, doesn't honor any user keys and hangs.

Steps-
1) open command prompt in windows 
2) "C:\Program Files (x86)\PuTTY\putty.exe" -ssh user at ip -T
3) in the pop-up putty window, enable the logging and write to a file..
4) Now if you press any key, the key is sent to the server but server
didn't acknowledge anything back.

I am attaching the putty logs that captures ssh packets and raw data
packets.
In the putty log, Line 335 shows "T" is been sent to SSH server but
there is no incoming packet from the SSH server..

Please let me know if you need more information.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> ---
I can reproduce this but I think PuTTY is at fault.  Or at least
there's a mismatch between what you expect and what PuTTY does.

I built sshd with -DPACKET_DEBUG I can see the keystroke arrive at the
server:

debug1: input: packet len 32
debug1: partial packet: block 16, need 16, maclen 20, authlen 0, aadlen
0
read_poll enc/full: buffer 0x80ff8ec0 len = 36
0000: 9d 58 ac 75 69 f6 e3 01 c9 4a 10 f7 97 44 3c 69  .X.ui....J...D<i
0016: 95 f0 18 77 7e 83 39 58 df ec b1 5c 33 ea 53 24  ...w~.9X...\3.S$
0032: 71 e1 02 b7                                      q...
debug1: MAC #9 ok
debug1: input: padlen 17
debug1: input: len before de-compress 10
read/plain[94]:
buffer 0x80ff6848 len = 9
0000: 00 00 00 00 00 00 00 01 54                       ........T

So the packet arrives but what happens to it?  I added "echo $$" to
the
shell startup and I see that, so the shell starts.   I straced the
shell after startup and I see:

read(0, "i", 1)                         = 1
read(0, "d", 1)                         = 1
read(0, "\r", 1)                        = 1
read(0, 

and compared this to ssh -T which doesn't hang when I do the same
thing:

read(0, "i", 1)                         = 1
read(0, "d", 1)                         = 1
read(0, "\n", 1)                        = 1
[shell proceeds to run and return output from "id"]

So, PuTTY isn't requesting a pty because you asked it not to, then it's
sending your keystrokes to the server which is getting them.  You're
not seeing anything because you don't have a pty and there's no
per-keystroke echo.  You don't see any output when you hit enter
because PuTTY sends a \r instead of the \n the shell is expecting, so
as far as the shell is concerned you're still entering a command.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

--- Comment #2 from balu <bagajjal at microsoft.com> ---
Thanks for the quick reply.

In the putty logs, it doesn't show the incoming packet so not sure if
the server is sending back the character to putty.

FYI, I tried the win32-openssh client, it works with the windows ssh
server (with -T option) but didn't work with the UNIX ssh server. So I
am guessing the per-keystroke echo is working fine and something else
is the issue.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to balu from comment #2)
> Thanks for the quick reply.
> 
> In the putty logs, it doesn't show the incoming packet so not sure
> if the server is sending back the character to putty.
It isn't because it shouldn't.
> FYI, I tried the win32-openssh client, it works with the windows ssh
> server (with -T option) but didn't work with the UNIX ssh server. So
> I am guessing the per-keystroke echo is working fine and something
> else is the issue.
I suspect that's due to the difference between Windows line endings
(\r\n) and Unix line endings (\n).  You could confirm that by
strace'ing the shell on the Unix side similar to what I did.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

--- Comment #4 from balu <bagajjal at microsoft.com> ---
(In reply to Darren Tucker from comment #3)
> (In reply to balu from comment #2)
> > Thanks for the quick reply.
> > 
> > In the putty logs, it doesn't show the incoming packet so not sure
> > if the server is sending back the character to putty.
> 
> It isn't because it shouldn't.
> 
> > FYI, I tried the win32-openssh client, it works with the windows ssh
> > server (with -T option) but didn't work with the UNIX ssh server.
So
> > I am guessing the per-keystroke echo is working fine and something
> > else is the issue.
> 
> I suspect that's due to the difference between Windows line endings
> (\r\n) and Unix line endings (\n).  You could confirm that by
> strace'ing the shell on the Unix side similar to what I did.
I modified the win32-openssh client to send "\n" instead of
"\r" so the
command gets executed but the per-keystroke echo is not working. 
Example - when I type "dir\n".. At the client side I see the output of
the dir but not the command "dir"..

I tried the same thing on the unix ssh client, it does echo the actual
command "dir".

Is there anything we need to do to show the per-keystroke echo?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> ---
(In reply to balu from comment #4)
[...]
> I modified the win32-openssh client to send "\n" instead of
"\r" so
> the command gets executed but the per-keystroke echo is not working.
As I keep telling you: there is no per keystroke echo without a pty!

Keystroke echo is a function of the tty layer (the pty in this case). 
I recommend reading the chapter on Terminal I/O in Richard Stevens'
_Advanced Programming in the Unix Environment_.

[..]
> Is there anything we need to do to show the per-keystroke echo?
Stop telling ssh to not request a pty.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #6 from Darren Tucker <dtucker at zip.com.au> ---
It does not look like there's anything in the code that OpenSSH ships
that is at fault here so I'm closing this bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

https://bugzilla.mindrot.org/show_bug.cgi?id=2743

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #7 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.