Currently, we are using Putty on Windows and OpenSSH on all other platforms. Having two implementations causes much work with maintaining and developing the SSH client. It would be much nicer to have one single implementation. Putty/plink is actually available for UNIX, but:
* It's smart card patch is not maintained and not accepted upstream.
* Putty is difficult to work with, due to it's complicated design.
So, I guess OpenSSH on Windows is a better path. A binary for Windows is actually available from the MinGW project, in the "MSYS Supplementary Tools" group (although I haven't tested it yet.)
To migrate to OpenSSH, we would need to adapt & build the NSS libraries for Windows, which might be somewhat difficult.
Unfortunately the version of OpenSSH in MSYS is ancient and of no use to us. So this will probably have to be a complete porting project.
Another reason to abandon putty is that the connection handling seems to be very crappy. A single invocation of plink results in three (!!) connections to the ssh server. Two of them are killed before a complete handshake is done, result in sshd filling the logs with "Did not receive identification string from 127.0.0.1".
When fixing this bug, make sure we enable PIN-with-PUK unlocking on the Windows client. Should perhaps document this as well.
Discussions are taking place on the TigerVNC mailinglist. A comment about Putty:
"The PuTTY project seems almost dead. "
"Yeah, the PuTTY project has not really released anything since about 2007. "
We should also move over public key handling to our tlclient agent implementation when we do this and clean out unnecessary messages in the pipe protocol parser.
Nomachine has apparently already ported OpenSSH:
Created attachment 421 [details]
A copy of the current version in case they remove it from their web site.
Works well enough to get a working session now. Still lots left to do though. SSH agent handling needs to be fixed, as well as host key management. And there's a massive amount of work in tlclient that needs to be sorted out.
Everything is now implemented. What is left is updating documentation, and clearing out everything PuTTY specific.
All done. Tester should examine all things SSH related. This includes all authentication forms, testing tunnels, etc. Tester should also check the source tree for any remaining occurrences of PuTTY.
Should attempt to push this upstream as well. Waiting for the Kerberos stuff to be finished first though.
Fails on Windows 7 (nightly build from 20130320):
NEXT AUTHMETHOD: none
NEXT AUTHMETHOD: publickey
NEXT AUTHMETHOD: password
PASSWORD: aaron zaphod
tcgetattr: Invalid argument
Last login: blahblahblah
Timeout, server zaphod not responding
(In reply to comment #12)
> Fails on Windows 7 (nightly build from 20130320):
Fixed in r26850. Did not affect tlclient though, only running ssh.exe by itself.
Another select() fix in r27049.
Handed off to upstream:
When connecting to a ip address that doesn't exists, client reports "Interal SSH error" when i expected to get "Connection timeout".
Reproducable on Win8 TL client build 3966.
2013-05-31T09:28:10: Log file created
2013-05-31T09:28:10: ThinLinc client release 4.0.0post build 3966
2013-05-31T09:28:23: SSH command: "C:\Program Files (x86)\ThinLinc Client\ssh.exe" -N -o GlobalKnownHostsFile=nul -o UserKnownHostsFile=nul -o PubkeyAuthentication=no -o CheckHostIP=no -o NumberOfPasswordPrompts=1 cendio@dhcp-254-196 -p 22 thinlinc-login master
2013-05-31T09:28:44: ssh[E]: CONNECT ERROR: -2147473588
(In reply to comment #16)
> When connecting to a ip address that doesn't exists, client reports "Interal
> SSH error" when i expected to get "Connection timeout".
Fixed in r27474.
- [X] Password authentication
- [X] Public key authentication
- [X] All changes pushed upstream
- [X] Smart card tunneling
- [X] Sound tunneling
- [X] Printing
- [X] No remnants of PuTTY in the source tree.
- [X] Smart card authentication
- [X] Local drive redirection
- [X] Handle locked smart cards
- [X] Unlock smart cards
- [X] Kerberos authentication
Already tested as part of bug 4003.
- [X] Serial console redirection
Connecting to /dev/ttyS0 gives you output in the tlclient.log from
sercd, and that's good enough for me.