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: http://www.nomachine.com/contributions
Created attachment 421 [details] openssh-5.9p1-win32.tar.gz 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 AUTH FAILURE NEXT AUTHMETHOD: publickey NEXT AUTHMETHOD: password PASSWORD: aaron zaphod AUTH SUCCESS CONNECTED 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: https://bugzilla.mindrot.org/show_bug.cgi?id=2104
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. tlclient.log. 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.
