PuTTY 0.68 is released

[Simon Tatham]

PuTTY version 0.68 is released
------------------------------

All the pre-built binaries, and the source code, are now available
from the PuTTY website at

http://www.chiark.greenend.org.uk/~sgtatham/putty/

This is mostly a feature update, but it also includes security fixes:

- Fixed a security vulnerability in the agent forwarding code. An
agent forwarding client could overwrite PuTTY's memory by sending a
particular kind of illegally formatted message. However, that is
less worrying than it sounds, because if a hostile client can
access your agent forwarding then you have other problems anyway!

- Fixed the widespread DLL hijacking issue seen in many Windows
programs. PuTTY should no longer accidentally load DLLs with
special names like 'ntmarta.dll' if they are in the same directory
as its executable file.

- Enabled some system security features in Windows PuTTY: Address
Space Layout Randomisation and Data Execution Prevention.

If any of those concerns you, you should upgrade as soon as possible.

We have also turned *off* (by default) the previous security feature
in which Windows PuTTY restricted its process ACL to make it harder
for malware to inject code into a running PuTTY. This feature was
causing too much assorted trouble with legitimate processes trying to
interoperate with PuTTY, ranging from screen reader software such as
NVDA to programs using Plink as a transport such as TortoiseGit. So
it's now off by default, but you can re-enable it using the
command-line option '-restrict-acl'.

That's enough about security. We also have lots of new features in
PuTTY 0.68:

- Support for elliptic-curve cryptography. PuTTY now supports public
and private keys using the Ed25519 signature algorithm, and also
the ECDSA algorithm using the three standard NIST curves. These
keys are supported for both user authentication and as host keys.
Also, elliptic-curve key exchange with both sets of curves is
supported (called 'Curve25519' and 'ECDH' respectively).

- PuTTYgen can now import and export keys in OpenSSH's newer file
format. (This is necessary for elliptic curve keys, but older key
algorithms like RSA are sometimes stored in the new format too.)

- When connecting to a server, PuTTY will now automatically prefer to
use a host key it already knows. But once you're connected, it also
has a new option to download the server's other host keys securely
over its existing connection and add them to its database so it can
use them next time. So if you want to upgrade to using elliptic-
curve keys for your existing servers, you can do that, and if you
don't care, then PuTTY shouldn't bother you about it.

- Windows: we are now offering a 64-bit version of PuTTY! This is
less well tested (so far), but it does its cryptography faster
during connection setup, and it can also load 64-bit DLLs if you
need that for some reason (e.g. GSSAPI).

- Unix: the Unix GUI tools can now be built with GTK version 3, which
offers improved font rendering and better support for precise
trackpad scrolling.

- Unix: we now have a Unix version of Pageant.

Enjoy using PuTTY!

--
for k in [pow(x,37,0x1a1298d262b49c895d47f) for x in [0x50deb914257022de7fff,
0x213558f2215127d5a2d1, 0x90c99e86d08b91218630, 0x109f3d0cfbf640c0beee7,
0xc83e01379a5fbec5fdd1, 0x19d3d70a8d567e388600e, 0x534e2f6e8a4a33155123]]:
print "".join([chr(32+3*((k>>x)&1))for x in range(79)]) # <ana...@pobox.com>

[juan.marti...@ineos.com]

Hi,

since I installed last PuTTY version (0.68) I am unable to connect to my home SSH server. After successful authentication (using keys) connection is closed with the following message 'Server unexpectedly closed network connection'

Connecting to the same SSH server using version 0.67 is working fine

Here below version details:

- OS = Windows 7 Professional 64 bits
- SSH server = Ice Cold Apps SSH server 3.1 on Android 4.2.2

Here below the interesting part of the logs on a failing connection (PuTTY 0.68):

Incoming packet #0x6, type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
Event Log: Access granted
Event Log: Opening session as main channel
Outgoing packet #0x7, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
00000000 00 00 00 07 73 65 73 73 69 6f 6e 00 00 01 00 00 ....session.....
00000010 00 40 00 00 00 40 00 .@...@.
Incoming packet #0x7, type 91 / 0x5b (SSH2_MSG_CHANNEL_OPEN_CONFIRMATION)
00000000 00 00 01 00 00 00 00 00 00 20 00 00 00 00 80 00 ......... ......
Event Log: Opened main channel
Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............
00000040 00 00 ..
Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 05 73 68 65 6c 6c 01 ........shell.
Event Log: Server unexpectedly closed network connection

And here below a successful connection to the same SSH server osing PuTTY 0.67:

Incoming packet #0x6, type 52 / 0x34 (SSH2_MSG_USERAUTH_SUCCESS)
Event Log: Access granted
Event Log: Opening session as main channel
Outgoing packet #0x7, type 90 / 0x5a (SSH2_MSG_CHANNEL_OPEN)
00000000 00 00 00 07 73 65 73 73 69 6f 6e 00 00 01 00 00 ....session.....
00000010 00 40 00 00 00 40 00 .@...@.
Incoming packet #0x7, type 91 / 0x5b (SSH2_MSG_CHANNEL_OPEN_CONFIRMATION)
00000000 00 00 01 00 00 00 00 00 00 20 00 00 00 00 80 00 ......... ......
Event Log: Opened main channel
Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 10 03 00 00 ................
00000030 00 7f 80 00 00 96 00 81 00 00 96 00 00 .............
Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 05 73 68 65 6c 6c 01 ........shell.
Incoming packet #0x8, type 99 / 0x63 (SSH2_MSG_CHANNEL_SUCCESS)
00000000 00 00 01 00 ....
Event Log: Allocated pty (ospeed 38400bps, ispeed 38400bps)
Incoming packet #0x9, type 99 / 0x63 (SSH2_MSG_CHANNEL_SUCCESS)
00000000 00 00 01 00 ....
Event Log: Started a shell/command
Incoming packet #0xa, type 94 / 0x5e (SSH2_MSG_CHANNEL_DATA)
00000000 00 00 01 00 00 00 00 13 75 30 5f 61 36 31 40 61 ........u0_a61@a
00000010 6e 64 72 6f 69 64 3a 2f 20 24 20 ndroid:/ $


Any idea on what's going on here?

BTW, I can successfully connect to other SSH servers (mainly on Ubuntu 16.04) using version 0.68, the only one failing is the Android one.

[Jacob Nevins]

juan.marti...@ineos.com writes:
>since I installed last PuTTY version (0.68) I am unable to connect to my
>home SSH server. After successful authentication (using keys) connection
>is closed with the following message 'Server unexpectedly closed network
>connection'
>
>Connecting to the same SSH server using version 0.67 is working fine

[...]

>- SSH server = Ice Cold Apps SSH server 3.1 on Android 4.2.2

[...]

>Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
> 00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
> 00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
> 00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
> 00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............
> 00000040 00 00 ..
>Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
> 00000000 00 00 00 00 00 00 00 05 73 68 65 6c 6c 01 ........shell.
>Event Log: Server unexpectedly closed network connection

Are there any logs on the server side that say anything useful?

Hunch: if you go to the SSH/TTY pane in PuTTY, find "IUTF8" in the
"Terminal modes" list, and press the "Remove" button, does that make a
difference?
(IUTF8 is new in 0.68, and that is in the pty-req packet that's one of
the last ones PuTTY sends before the server slams the connection shut.)

[juan.marti...@ineos.com]

> Are there any logs on the server side that say anything useful?
>
> Hunch: if you go to the SSH/TTY pane in PuTTY, find "IUTF8" in the
> "Terminal modes" list, and press the "Remove" button, does that make a
> difference?
> (IUTF8 is new in 0.68, and that is in the pty-req packet that's one of
> the last ones PuTTY sends before the server slams the connection shut.)

Nothing interesting is logged on the server.

IUTF8 is not selected in PuTTY 0.68. In fact, terminal modes to send are the same on 0.67 and 0.68 but the pty-req packet is slightly different, see below

0.67

Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...

00000020 18 00 00 00 00 00 00 00 00 00 00 00 10 03 00 00 ................
00000030 00 7f 80 00 00 96 00 81 00 00 96 00 00 .............

0.68

[Jacob Nevins]

juan.marti...@ineos.com writes:
>IUTF8 is not selected in PuTTY 0.68. In fact, terminal modes to send are
>the same on 0.67 and 0.68

Are you sure?

IUTF8 should have been added to existing settings automatically when you
upgraded. And it's quite hard to verify that the list is the same in the
tiny window we give you.

Because:

>but the pty-req packet is slightly different, see below
>
>0.67
>
>Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
> 00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
> 00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
> 00000020 18 00 00 00 00 00 00 00 00 00 00 00 10 03 00 00 ................
> 00000030 00 7f 80 00 00 96 00 81 00 00 96 00 00 .............

The terminal modes in this translate to:

0x03: 0x7F (VERASE)
0x80: 0x9600 (TTY_OP_ISPEED)
0x81: 0x9600 (TTY_OP_OSPEED)

>0.68
>
>Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
> 00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
> 00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
> 00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
> 00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............
> 00000040 00 00

0x03: 0x7F (VERASE)
0x2A: 0x01 (IUTF8)
0x80: 0x9600 (TTY_OP_ISPEED)
0x81: 0x9600 (TTY_OP_OSPEED)

So IUTF8 is there, and may be what's upsetting your server.
(This is a new mode recently added to the SSH protocol:
<http://tools.ietf.org/html/draft-sgtatham-secsh-iutf8>)

[Juan Martinez]

El martes, 28 de febrero de 2017, 17:18:35 (UTC+1), Jacob Nevins escribió:

> Juan Martinez writes:
> >IUTF8 is not selected in PuTTY 0.68. In fact, terminal modes to send are
> >the same on 0.67 and 0.68
>
> Are you sure?
>

Yes, I double checked this and IUTF8 is not selected. I also checked the corresponding key on windows registry and IUTF8 is not present, see below:

CS7=A,CS8=A,DISCARD=A,DSUSP=A,ECHO=A,ECHOCTL=A,ECHOE=A,ECHOK=A,ECHOKE=A,ECHONL=A,EOF=A,EOL=A,EOL2=A,ERASE=A,FLUSH=A,ICANON=A,ICRNL=A,IEXTEN=A,IGNCR=A,IGNPAR=A,IMAXBEL=A,INLCR=A,INPCK=A,INTR=A,ISIG=A,ISTRIP=A,IUCLC=A,IXANY=A,IXOFF=A,IXON=A,KILL=A,LNEXT=A,NOFLSH=A,OCRNL=A,OLCUC=A,ONLCR=A,ONLRET=A,ONOCR=A,OPOST=A,PARENB=A,PARMRK=A,PENDIN=A,QUIT=A,REPRINT=A,START=A,STATUS=A,STOP=A,SUSP=A,SWTCH=A,TOSTOP=A,WERASE=A,XCASE=A

Still the SSH2_MSG_CHANNEL_REQUEST packed sent to the server is the one containing IUTF8. It looks like this option is always sent to the server no matter the setting value.

[Jacob Nevins]

Juan Martinez <juan.marti...@ineos.com> writes:
>Yes, I double checked this and IUTF8 is not selected. I also checked the
>corresponding key on windows registry and IUTF8 is not present, see
>below:

[...]

>Still the SSH2_MSG_CHANNEL_REQUEST packed sent to the server is the one
>containing IUTF8. It looks like this option is always sent to the server
>no matter the setting value.

Oh dear, several PuTTY bugs here.

1. A commit we made in preparation for adding the IUTF8 mode (2ce0b680)
accidentally removed the ability to configure the PuTTY tools not to
send a given terminal mode.
(In pursuit of sending it by default even for people with old saved
sessions, because usually it's either harmless or beneficial.)

This isn't noticeable for most modes, because they default to 'auto'
and PuTTY doesn't have an opinion on them so doesn't send them. But
the terminal emulator has an opinion on IUTF8 (based on the selected
character set), so always sets it.

2. The configuration UI displays what the setting says, not what PuTTY
is going to actually send, so it doesn't mention any new modes added
since the session was saved.

So, there's no way for you to test what I want you to test in PuTTY
proper -- whether it's the IUTF8 mode that's upsetting your server. And
if it is, there's currently no workaround.

However, you can test it in Windows plink.exe 0.68 -- that doesn't
express an opinion on IUTF8, so you can create a variety of saved
sessions with IUTF8 set to "auto" (which won't send it), "yes", and
"no", and see how your server reacts to each of these. It would be
helpful if you could tell us the results.

Also, can you send the "Server version" line from your log file, in case
we decide to add an automatic bug-compatibility mode for this?

(It would be nice if this server didn't kill the connection on seeing
what is presumably a mode unknown to it, assuming that turns out to be
the cause. RFC4254 s8 merely says "the server MAY ignore any modes it
does not know about", but the fact that new assignments are provided for
by RFC4250 suggests that ignoring unknown modes would be a good plan.)

>CS7=A,CS8=A,DISCARD=A,DSUSP=A,ECHO=A,ECHOCTL=A,ECHOE=A,ECHOK=A,ECHOKE=A,ECHONL=A,EOF=A,EOL=A,EOL2=A,ERASE=A,FLUSH=A,ICANON=A,ICRNL=A,IEXTEN=A,IGNCR=A,IGNPAR=A,IMAXBEL=A,INLCR=A,INPCK=A,INTR=A,ISIG=A,ISTRIP=A,IUCLC=A,IXANY=A,IXOFF=A,IXON=A,KILL=A,LNEXT=A,NOFLSH=A,OCRNL=A,OLCUC=A,ONLCR=A,ONLRET=A,ONOCR=A,OPOST=A,PARENB=A,PARMRK=A,PENDIN=A,QUIT=A,REPRINT=A,START=A,STATUS=A,STOP=A,SUSP=A,SWTCH=A,TOSTOP=A,WERASE=A,XCASE=A

(Oddly, this setting is different from PuTTY 0.67's default in that it
lacks "PARODD=A". But I don't think that makes any difference here.)

[Juan Martinez]

El martes, 28 de febrero de 2017, 23:53:15 (UTC+1), Jacob Nevins escribió:

> However, you can test it in Windows plink.exe 0.68 -- that doesn't
> express an opinion on IUTF8, so you can create a variety of saved
> sessions with IUTF8 set to "auto" (which won't send it), "yes", and
> "no", and see how your server reacts to each of these. It would be
> helpful if you could tell us the results.

Bingo! Tested with plink, IUTF8=auto or no, connection succeed, IUTF8=yes, connection fails

> Also, can you send the "Server version" line from your log file, in case
> we decide to add an automatic bug-compatibility mode for this?

Here it is:

Event Log: Server version: SSH-2.0-SSH Server - My home SSH server

unfortunately "My home SSH server" part is user defined, I am not sure you can do much with the remaining part which looks quite generic

[Jacob Nevins]

Juan Martinez <juan.marti...@ineos.com> writes:
>Bingo! Tested with plink, IUTF8=auto or no, connection succeed,
>IUTF8=yes, connection fails

Aha. Then you have a workaround for PuTTY proper -- setting IUTF8
explicitly to "no" instead of "auto" should allow you to connect, I
think.

I'll look at restoring the ability not to send this mode at all.

>Event Log: Server version: SSH-2.0-SSH Server - My home SSH server
>
>unfortunately "My home SSH server" part is user defined, I am not sure
>you can do much with the remaining part which looks quite generic

Sigh, yes, probably not a lot we can do with that.

[Juan Martinez]

El miércoles, 1 de marzo de 2017, 16:31:48 (UTC+1), Jacob Nevins escribió:
> Aha. Then you have a workaround for PuTTY proper -- setting IUTF8
> explicitly to "no" instead of "auto" should allow you to connect, I
> think.

I've already tried this without success, when I set IUTF8 to no I see that "IUTF8=Vno" appears on TerminalModes key, but still the the wrong packet is sent to the server.

My understanding was that is was due to this

[Jacob Nevins]

Juan Martinez <juan.marti...@ineos.com> writes:
> El miércoles, 1 de marzo de 2017, 16:31:48 (UTC+1), Jacob Nevins escribió:

>> [Juan Martinez:]

>>> Bingo! Tested with plink, IUTF8=auto or no, connection succeed,
>>> IUTF8=yes, connection fails
>>

>> Aha. Then you have a workaround for PuTTY proper -- setting IUTF8
>> explicitly to "no" instead of "auto" should allow you to connect, I
>> think.
>
> I've already tried this without success,

That is, the server slams the connection shut when you use this setting
with PuTTY proper?

That's odd, given that you reported that the same setting worked with
Plink.

> when I set IUTF8 to no I see that "IUTF8=Vno" appears on TerminalModes key,

Good.

> but still the the wrong packet is sent to the server.

With IUTF8 set to "no" I would expect the following byte sequence in the
pty-req packet: 2a 00 00 00 00. Do you see that?

The following table shows the byte sequences I would expect from
different settings, and the behaviour you have so far reported.

IUTF8 Plink PuTTY
Byte seq Result Byte seq Result
"(auto)" <no 2A> Connect 2a 00 00 00 01* No connect
"This: no" 2a 00 00 00 00 Connect 2a 00 00 00 00 No connect??
"This: yes" 2a 00 00 00 01 No connect 2a 00 00 00 01 ?
absent <no 2A> <can't do> <no 2A> <can't do>

* iff character set configured as UTF-8 (the default); otherwise ...00

My initial hypothesis was that the server was either reacting badly to
the presence of the key 2A at all. Your results with Plink suggests that
your server was fine with that key provided the value was 0. But your
latest report with PuTTY just confuses me.

> My understanding was that is was due to this
>
>> 1. A commit we made in preparation for adding the IUTF8 mode (2ce0b680)
>> accidentally removed the ability to configure the PuTTY tools not to
>> send a given terminal mode.

This is about an inability to not send the mode. Sending the mode with a
value of 0 is different from not sending it at all, and should still be
possible.

[Juan Martinez]

El jueves, 2 de marzo de 2017, 11:09:37 (UTC+1), Jacob Nevins escribió:
> That is, the server slams the connection shut when you use this setting
> with PuTTY proper?

Yes

> That's odd, given that you reported that the same setting worked with
> Plink.

Well, it seems that I somehow forgot to save settings while testing with plink, I was just modifying Default Settings on PuTTY and connecting with plink.

> With IUTF8 set to "no" I would expect the following byte sequence in the
> pty-req packet: 2a 00 00 00 00. Do you see that?

Yes

I performed those tests again, connecting with PuTTY and plink with IUTF8 set to auto, yes, no and absent respectively.

Using PuTTY, the 2a 00 00 00 00 or 2a 00 00 00 01 sequence appears every time and all connections fail.

Using plink, the sequence is absent if IUTF8 is either set to auto or absent, in that case connection is successful. In all other cases either 2a 00 00 00 00 or 2a 00 00 00 01 sequence is there and those connections fail.

So it looks like what the server is not happy with are those byte sequences, connections are successful only IF the sequences are absent.

Here below the whole packets from those tests:

PuTTY - IUTF8 = auto
Connection fails

Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............

00000040 00 00 ..

plink - IUTF8 = auto
Connection succeed

Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)

00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...

00000020 18 00 00 00 00 00 00 00 00 00 00 00 0b 80 00 00 ................
00000030 96 00 81 00 00 96 00 00 ........

PuTTY - IUFT8 = yes
Connection fails

Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............

00000040 00 00 ..

plink - IUTF8 = yes
Connection fails

Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)

00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...

00000020 18 00 00 00 00 00 00 00 00 00 00 00 10 2a 00 00 .............*..
00000030 00 01 80 00 00 96 00 81 00 00 96 00 00 .............

PuTTY - IUTF8 = no
Connection fails

Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................

00000030 00 7f 2a 00 00 00 00 80 00 00 96 00 81 00 00 96 ..*.............
00000040 00 00 ..

plink - IUTF8 = no
Connection fails

Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)

00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...

00000020 18 00 00 00 00 00 00 00 00 00 00 00 10 2a 00 00 .............*..
00000030 00 00 80 00 00 96 00 81 00 00 96 00 00 .............

PuTTY - IUTF8 = absent
Connection fails

Outgoing packet #0x8, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)
00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...
00000020 18 00 00 00 00 00 00 00 00 00 00 00 15 03 00 00 ................
00000030 00 7f 2a 00 00 00 01 80 00 00 96 00 81 00 00 96 ..*.............

00000040 00 00 ..

plink - IUTF8 = absent
Connection suceed

Outgoing packet #0x9, type 98 / 0x62 (SSH2_MSG_CHANNEL_REQUEST)

00000000 00 00 00 00 00 00 00 07 70 74 79 2d 72 65 71 01 ........pty-req.
00000010 00 00 00 05 78 74 65 72 6d 00 00 00 50 00 00 00 ....xterm...P...

00000020 18 00 00 00 00 00 00 00 00 00 00 00 0b 80 00 00 ................
00000030 96 00 81 00 00 96 00 00 ........

[Jacob Nevins]

Juan Martinez <juan.marti...@ineos.com> writes:
>Well, it seems that I somehow forgot to save settings while testing with
>plink, I was just modifying Default Settings on PuTTY and connecting
>with plink.

[...]

>Using plink, the sequence is absent if IUTF8 is either set to auto or
>absent, in that case connection is successful. In all other cases either
>2a 00 00 00 00 or 2a 00 00 00 01 sequence is there and those connections
>fail.

Right, so my first guess was right: the Ice Cold Apps SSH server[*]
objects to any mention of IUTF8 (and, I'm guessing, any other terminal
mode it hasn't heard of).

Which means you're SOL until we fix PuTTY upstream to allow you not to
send IUTF8 (unless you can build your own). I have a plan, but I may not
get to it for a few days.

Workarounds include downgrading to 0.67 (having reviewed the
vulnerabilities), or setting "Don't allocate a pseudo-terminal" and then
probably bludgeoning other settings (edit/echo etc) until you get a
vaguely usable terminal experience back.

It's possible that this might happen this with other clients too.
OpenSSH 7.3 release notes say "Implement support for the IUTF8 terminal
mode as per draft-sgtatham-secsh-iutf8-00"; don't know if that means
it'll send IUTF8 by default (that would be the useful thing to have
done).

[*] This one, right?:
<https://play.google.com/store/apps/details?id=com.icecoldapps.sshserver&hl=en>
Is it running on your phone or tablet or something?

Don't suppose you fancy reporting this as a bug to them?

[juan.marti...@ineos.com]

El jueves, 2 de marzo de 2017, 16:17:20 (UTC+1), Jacob Nevins escribió:
> >Using plink, the sequence is absent if IUTF8 is either set to auto or
> >absent, in that case connection is successful. In all other cases either
> >2a 00 00 00 00 or 2a 00 00 00 01 sequence is there and those connections
> >fail.
>
> Right, so my first guess was right: the Ice Cold Apps SSH server[*]
> objects to any mention of IUTF8 (and, I'm guessing, any other terminal
> mode it hasn't heard of).

Yep, you are probably right.

> Which means you're SOL until we fix PuTTY upstream to allow you not to
> send IUTF8 (unless you can build your own). I have a plan, but I may not
> get to it for a few days.
>
> Workarounds include downgrading to 0.67 (having reviewed the
> vulnerabilities), or setting "Don't allocate a pseudo-terminal" and then
> probably bludgeoning other settings (edit/echo etc) until you get a
> vaguely usable terminal experience back.

I've already downgraded to 0.67, I can live with the vulnerabilities listed at <http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html>

> [*] This one, right?:
> <https://play.google.com/store/apps/details?id=com.icecoldapps.sshserver&hl=en>

Yes, that one.

> Is it running on your phone or tablet or something?

It is running on an Android TV Box sitting next to my TV. I mainly use it to SFTP to an external USB drive connected to it when I am away from home, but from time to time I need to log in to the console as well.

> Don't suppose you fancy reporting this as a bug to them?

Will do, but I do not expect them to respond as fast as you did ;-) This application has not been modified since 4 years now.

In any case, thank you very much for your help.

[Jacob Nevins]

juan.marti...@ineos.com writes:
>El jueves, 2 de marzo de 2017, 16:17:20 (UTC+1), Jacob Nevins escribió:
>> Right, so my first guess was right: the Ice Cold Apps SSH server[*]
>> objects to any mention of IUTF8 (and, I'm guessing, any other terminal
>> mode it hasn't heard of).
>
>Yep, you are probably right.
>
>> Which means you're SOL until we fix PuTTY upstream to allow you not to
>> send IUTF8 (unless you can build your own). I have a plan, but I may not
>> get to it for a few days.

You should find that today's snapshot (available at
<http://www.chiark.greenend.org.uk/~sgtatham/putty/snapshot.html>)
allows you to disable the sending of the IUTF8 terminal mode.

If you have time to try it with your server and confirm that it allows
you to connect with PuTTY proper, that would be useful.

[juan.marti...@ineos.com]

El martes, 7 de marzo de 2017, 10:51:47 (UTC+1), Jacob Nevins escribió:
> You should find that today's snapshot (available at
> <http://www.chiark.greenend.org.uk/~sgtatham/putty/snapshot.html>)
> allows you to disable the sending of the IUTF8 terminal mode.
>
> If you have time to try it with your server and confirm that it allows
> you to connect with PuTTY proper, that would be useful.

Just tried it and it's working fine.

BTW, 'Remote terminal settings' UI looks much clearer/cleaner now

[Olaf]

Hi,

I have a problem since I am using 0.68

- PuTTY no longer offers a history of sessions
- the Windows 7 taskbar icon that I am using to start PuTTY does not
change to the usual "app running" state. Instead, I get an additional
PuTTY icon on the task bar.

Is there a way to do a reset of all PuTTY settings?

Olaf

[Jacob Nevins]

Olaf <ol...@spamtrap.eu.org> writes:
>I have a problem since I am using 0.68
>
>- PuTTY no longer offers a history of sessions
>- the Windows 7 taskbar icon that I am using to start PuTTY does not
>change to the usual "app running" state. Instead, I get an additional
>PuTTY icon on the task bar.

This is a known issue, although we don't fully understand it yet.
<http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-jumplist-trouble.html>

>Is there a way to do a reset of all PuTTY settings?

The above link describes some options you have. Let us know how you get
on, if you try them.