According to the report, this also applies to OpenSSH client

Yes. The versions are OpenSSH 5.7 - 8.3, PuTTY 0.68 - 0.73.

We've changed the URL from https://nvd.nist.gov/vuln/detail/CVE-2020-14002 to what seems to be the original source, via https://www.fzi.de/en/news/news/detail-en/artikel/fsa-2020-2..., which the former article links to.

The comments in this thread are all about PuTTY, which no doubt is because that's all the other article mentioned.

https://www.chiark.greenend.org.uk/~sgtatham/putty/ 2020-06-27 PuTTY 0.74 released

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.

[1]: https://git-scm.com/

Note also that ssh and scp (from OpenSSH) are included in Windows by default since 2018.

Another alt is Cygwin

https://cygwin.com/

Windows 10 comes with OpenSSH installed by default now -- start up PowerShell and run `ssh`. Includes all the trimmings, even a `ssh-agent`.

Of course, if you don't like the rendering/look/customization of the default PowerShell window, you can also grab Windows Terminal: https://www.microsoft.com/en-us/p/windows-terminal/9n0dx20hk...

I use msys2 directly instead.

https://www.msys2.org/

WSL is, IMHO, another good option.

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.

You don't need WSL. Windows10 supports OpenSSH

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.

I set it up. As a service. Check stackoverflow.

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 use openssh from powershell. You can install it as a package or feature I believe.

But WSL also supports lots of other useful things!

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.

The terminal emulation in Windows 10 isn't great. Mostly I use PuTTY instead.

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).

Putty's absurdly small gui that isn't resizable was one of those minor things that always made my eye twitch. UX from a different age.

Why do you need to resize it?

Why do you need to change your wallpaper?

What does this have to do with my question lol

I think he's implying that customization is pretty much something you take for granted and there is no real reason it's not in putty.

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.

Putty doesn’t implement 256 colors properly which is why there is so much eye bleating blue.

Not everyone has the luxury of running Linux host.

How about clipboard integration?

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.

different key file format is pain.

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.

Yeah and I'm surprised everyone forgot how much of a closed down oppressive shit windows 10 is...

Sorry, not buying into the Extend phase. Thank god for Putty and win7 combination still working.

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.

I believe they will get there with Windows terminal (https://github.com/Microsoft/Terminal), I just don’t think they are there yet.

PuTTY also works with telnet and serial ports. I'll never stop using it.

This. Mine is eternally used as a console for some bit of network gubbins that still has a usb serial port in it (Cisco etc)

Even better, WSL isn’t required these days. There is a full version of ssh in the standard cmd terminal.

They didn’t launch it with a big splash or anything, but it has saved my butt before.

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?

You can edit the ssh/config file to create/define aliases. For each alias, you can configure the host, port, username, etc.

Ahhh, fantastic. Somehow I was never aware of this. Will try it out, thanks!

Isn't it just regular OpenSSH, where you enter settings and aliases for hosts in ~/.ssh/config?

in ~/.ssh/config:

    Host *
    (options)

You actually believe using a virtualized system just for an SSH client is somehow preferable to a native application?

In WSL2 isn't that a full-blown VM with another kernel and all? To run an SSH client? shakes head in disbelief

No need for either, windows has and OpenSSH client and server as well as pretty good terminal now.

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.

I recently installed it because WSL2 can't talk to hardware, so I use it for devices connected using a USB to UART cable.

Is the terminal emulation fixed? Every time I tried to use WSL, some kind of glitch shows up when I am SSH’d into a server.

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.

Yeah it’s awful. Window terminal default key bindings buggers up touch as well.

I have moved to macOS since wsl2 came out.

Unfortunately lots of organizations haven't switched to Windows 10 yet, despite end of support.

Hello there, from an employee of a major health care network which still has a ton of Windows Server 2003 servers in production!

Hello there! From someone who was asked if they still support Windows 2000.

I use it only when I need to connect via serial

The EU has a $90k bounty for bugs in putty,did anyone collect on this?

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.

Mozilla has a pretty good guide for those config options:

https://infosec.mozilla.org/guidelines/openssh.html

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.

SSH supports things like pinning the key in a DNSSEC response.

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.

The linked paper here https://www.fzi.de/en/news/news/detail-en/artikel/fsa-2020-2... goes into detail. The PDF is in English, despite the German URL.

Yes,

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.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connecti...

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.

Nah, it's normal to have URLs like that for software, especially for power user or administration or developer utilities.

Everyone recognizes that URL. It would be more suspect to download PuTTY from anywhere else.

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.

> Everyone recognizes that URL. It would be more suspect to download PuTTY from anywhere else.

that that to everyone who downloaded from putty.org

I recognize the general pattern of the URL but if you changed a character here or there I wouldn't notice it.

The lack of any style on the page tells you it's legit.

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.

> PuTTY Initial Release: January 8, 1999

> OpenSSH Initial Release: 1 December 1999

Via Wikipedia

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.

On the other hand, this bug only affects PuTTY users instead of all openssh users, which means it’s that much less of an appealing target for Hackers.

This bug actually affects OpenSSH, too. See https://www.fzi.de/en/news/news/detail-en/artikel/fsa-2020-2...

Very surprised to see a bug get patched in putty but says OpenSSH won't fix. Anyone reading this with the kind of background who can comment on that?

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. ”