An alternative to putty on windows is to get the entire Git SCM package[1]. You get not just git, ssh and sftp but many other useful command line tools too.
I'm surprised people are still using PuTTY this much. It used to be one of the first programs I'd install on any new Windows machine and has served me well for many years. But since I started using WSL I haven't needed it once.
PuTTY has been doing this job for however many years, why change?
I don't want to run a whole VM so I can ssh to a real machine. I don't trust Microsoft with providing a decent terminal experience, were I to run their ssh in their terminal. Frankly, at this point, anything new from Microsoft that does something I can already do is suspect; their new work doesn't feel polished and I'm tired of trying their broken stuff.
I also use the win10 openssh. Sometimes it is not so great at terminal emulation in a way that a Unix environment will expect. For example I get frequent weird behaviors running vi. Maybe could be fixed with TERM or termcap but putty "just works".
Also I haven't seemed to be able to get ssh-agent working there. Maybe just need to look into it more.
On the agent thing: I don't know about the OpenSSH agent, but I have KeeAgent set up and it works without a hitch in MSYS (and thus Git Bash) as well as with the SSH port of Microsoft.
the Windows Terminal is.. while significantly better than ever - its still not great, the lack of bell support, and you effectively need to run whatever you're doing inside screen to make curses applications run correctly.
I'm using PuTTY because I prefer native software. That said, it seems that Microsoft started shipping its own build of OpenSSH with Windows 10, so probably that's not needed anymore.
I agree about the default terminal emulation, although Microsoft's new Terminal application has improved much of it.
But I find PuTTY's terminals to be almost worse. The visuals are seriously eye cancer inducing, and PuTTY's tools don't seem to be built with a terminal-based workflow in mind.
So, I much rather use either MS' OpenSSH port (on Win10) or MSYS 2's (which is included in the Git Bash for Windows, too).
Why is it not great? I just opened session from cmd.exe to a Linux host and checked few things. Colors work, vim works, tmux works, arrow keys work, delete and backspace works. From a quick test the only issue I've found is input with cyrillic layout, but that's definitely not something to be concerned about.
It's slow, the clipboard integration is flaky, the resize behaviour is weird. And difficulties with non-ascii input are a serious problem for some of us.
Not sure about speed, but clipboard integration works for me from the first glance (see my neighbor answer) and resize works, at least for vim and tmux. Non-ascii input requires more research, I think that with some additional configuration it should work.
To copy text, selecting and pressing <Enter> or <Ctrl>+C works. To paste, one should right-click window title and select Edit -> Paste (Ctrl+V and Shift+Insert are sent as a hotkeys to the Linux). Or just right-click terminal window.
Another approach is to enable "Use Ctrl+Shift+C/V as Copy/Paste" in terminal properties and just use those shortcuts, they seem to work fine in ssh.
Been using PuTTY since 1999 and I haven't had a reason to switch. The only thing I don't like about it is that you have to dump the registry to back up your saved sessions.
The issue with everything which is not PuTTY is terminal emulation bugs, in my experience. I’ve never experienced one in PuTTY or at least not noticeably. Whereas using SSH in every other Windows terminal (including the newer windows terminal emulator they’ve been working on), I eventually run into display bugs requiring me to refresh the terminal somehow, particularly in long running tmux sessions.
Stupid question: while I dislike the UX of Putty's settings screen, at least it lets me load/save a bunch of hosts with default settings. How do you do that with command like ssh? Do people just remember IP addresses or something, or is there a trick I'm not aware of?
I use Royal TS. It’s basically a MDI in which you can include many PuTTY etc. sessions. Also allows you to simultaneously perform commands on all open terminals. Handy if you administer a large set of servers.
It's not. Default wsl terminal is pretty much unusable if you need anything more complex than entering commands (read vim and tmux). You can install MinTTY terminal for wsl, but it's much more hassle then just download putty.
It's a good idea to explicitly set the "Ciphers", "HostKeyAlgorithms", "KexAlgorithms", and "MACs" options to your preferred values (in your ssh_config and sshd_config files) anyways... but, as a bonus, the issue doesn't affect you if you have (according to the document).
If you set these options yourself rather than depending on your upstream distro defaults, be prepared to experience surprising and unexpected incompatibilities with SSH; by making your own choices, you are accepting additional responsibilities for debugging compatibility issues that will arise. When you encounter issues with anything SSH-related, be sure you've checked your SSH client/server in verbose mode to verify that it is not a PEBCAK issue before seeking technical support from others, and be sure to include your custom values for those options when reporting SSH issues to others so that everyone doesn't waste time trying (uselessly) to repro your issue without them.
If you don’t know the host key you are always vulnerable to a man in the middle attack. Is this really a vulnerability in Putty or a design weakness in SSH?
It's an intentional design decision. Unlike https, ssh doesn't typically use x509 certificates for authentication, so there's no real way to know whether you're MITM if you're making a connection for the first time.
Modern SSH of course does support certificates --- SSH certificates aren't X.509 --- which solve this problem, the key management problem, and the long-term SSH key hazmat problem. Probably, SSH certificates are what we should have been using all along.
The article is so low on details. I wish there was a more in-depth explanation. Isn't the first connection (with unknown host key) always a target for MitM attacks and thus insecure, unless you preload the host key?
The leak allows an attacker to distinguish first connections that are made without a cached host key, allowing them to target those connections only and reduce their risk of detection.
OpenSSH seems affected, too, but have decided to not fix this. As far as I understand the paper, any fix may have undesirable side effects.
That is exactly the reported issue here. PuTTY 0.68 through 0.73 allows the remote attacker to accurately determine whether or not the client has cached the host key. It looks like this works because PuTTY sends a different algorithm list depending on whether or not the key has been cached.
If the MiTM attacker sees the 'default algorithm list' it can be assumed that this is the first connection attempt and the attacker can substitute the server key with a compromised key.
Ah, that's cool. I pushed AWS to give better ways of getting the host key for new EC2 instances a few years back. The whole start an EC2 instance, SSH in and blinkly trust the host key on first use thing seemed terrible!
EC2 docs now include that detail, although its labeled as optional.
Does anyone else get sketched out about downloading putty from the official URL? I know its been around for awhile, but still seems like a suspect URL for such a popular program.
As an infrequent user of PuTTY, I don't recognize that URL. So I guess I'm not part of the "everyone" you're talking about.
On the other hand, I think it's absolutely ridiculous to base one's security around URL recognition, considering all the possible attacks against domain names and URLs.
Cryptographic signatures in a web of trust would be a big step forward here, but unfortunately relatively few people participate.
There's a lot said about the benefits of competing implementations: browsers, web frameworks, what-have-you.
There are certain categories of security-critical software where I feel like it's only increasing surface area for bugs. The idea that PuTTY has bugs that aren't originating from the openssh project is really bothersome to me. All that work to reimplement, for what?
PuTTY was written back in a time when SSH was proprietary software. It predates the first release of OpenSSH, which I believe was BSD-only at the time, by almost a year.
That aside, the official SSH implementation has never been any princess either. The PuTTY implementation is superior in many ways, not least in terms of modularity, although evidently just as prone to security problems as OpenSSH.
I'm all for new alternative implementations of important pieces of our stack, but please God no more security-critical C.
> The idea that PuTTY has bugs that aren't originating from the openssh project is really bothersome to me. All that work to reimplement, for what?
Agreed. OpenSSH wasted a lot of needless effort reimplementing PuTTY. Except now that you know the timeline is reversed I expect your opinion on reimplementation to suddenly 180 as well.
Note, OpenSSH wasn't brand new code on its first release. It was forked from the original SSH software from a version before it went commercial. I can't remember the whole history of that earlier open source project, but I can remember that I installed it on a university workstation in mid 1996.
If I read the report correctly, this is a protocol level issue. The report lists a potential client side fix, but it’s not without
problems and includes the following sentence regarding openssh: “ The developers of OpenSSH are not planning to change the behavior of OpenSSH regarding this issue, because of the aforementioned drawbacks. ”
