Hacker News Reader

Comment by MaxBarraclough | Hacker News Reader

I'd generally recommend HTTPS, simply because most developers cannot be trusted to manually verify SSH public keys/fingerprints. Most will blindly approve whatever fingerprint they are shown, opening the door to man-in-the-middle attacks.

This isn't just an issue during initial set-up. If the Git host rotates their keys, it will need the client to accept the new keys. If your developers are sloppy and unthinkingly approve the new fingerprint, that means they're vulnerable to a MitM attack at any moment; presumably they'd unthinkingly approve an attacker's fingerprint too.

With HTTPS, you inherit the web's CA model, and it's pretty much secure-by-default.

View on HN

PSA that Github publishes their fingerprints here: https://docs.github.com/en/authentication/keeping-your-accou...

Also, when you’re asked to verify the fingerprint, you can copy and paste the matching one from that known-good list instead of blindly typing “yes.” That way SSH will do the comparison for you.

If you do this, your usage of SSH with Github is as good as TLS (since the fingerprints are served via TLS).

If your developers are sloppy about security does that not create a lot of other problems too?

Is this a UI issue to some extent? Its easy to type "y"/click yes to accept a changed finger print, but takes effort to type "Verify=false" (if I have got that right) to accept a bad certificate.

> If your developers are sloppy about security does that not create a lot of other problems too?

Yes, but: devs can be sloppy about ssh key security and better (yet still imperfect) at other things. Also, it's worth continually making improvements in some areas even if we can't fix everything. Which is good. We'll never be able to fix everything.

I wish certificate signed host keys were easier to roll out and maintain. That's a marked improvement, even if it has its own flaws.

This seems like it could be solved easily enough. Just add a feature to ssh for rotating keys securely. Each new key issued by the server could be signed by the previous (already trusted) key. If the chain is ever broken and an unsigned key is issued (after initial setup) then ssh could simply bail out and refuse to connect with a scary message warning you to contact the administrators, as it does now every time keys change.

The problem right now is that if you rotate keys frequently your users get desensitized to the scary message and end up following the drill to delete the current key and connect with the new one. With a secure signing chain for rotating keys you avoid this problem.

You can set up SSH to use certs and then add the server cert to your known_hosts file instead of the individual host keys. Then when the host keys rotate, all is well as long as the new host keys are signed by the same cert.

> Each new key issued by the server could be signed by the previous (already trusted) key

That doesn't work if the host's private key is leaked, or may have been leaked, e.g. [0][1].

The current solution seems ok; we go through another channel to confirm the new key, likely either receiving an email about the key change, or using the web.

[0] https://github.blog/news-insights/company-news/we-updated-ou...

[1] https://bitbucket.org/blog/ssh-host-key-changes

Respectfully, it seems that your actual problem is that you work with developers who can't be trusted to manually verify SSH public keys/fingerprints, not that SSH is complicated.

Defaulting to HTTPS just because it is easier for them feels like a no-solution, but I could be generalizing. Maybe you are talking about developers in training or L1 levels.

I don’t understand the pompous hostility here.

Choosing a default that requires less effort to verify the security of is never a bad idea, especially if you know the limitations of the people at place you’re in. It isn’t worth teaching everyone everything about SSH on top of one’s normal set of daily tasks.

Let’s settle into reality for a hot minute: absolutely nobody is getting fired over “what’s the point of a SSH server’s public key”

Hey, my bad if I came off as hostile before. Didn't mean to.

My perspective comes from spending lot of time training and onboarding devs. Devs can level up their skills if you give them a chance. That's why I push for upskilling rather than dumbing things down.

I get where you're coming from with the SSH key stuff. And yeah, it's practical to go with easier options most of the time. You're right that no one's getting fired over SSH keys. But hey, learning this stuff can make the team stronger in the long run.

I understand this is a petty example as Senior developers can be flexible about these things and strong-minded about others.

The majority of developers do not verify SSH fingerprints. If the majority are not following a process that makes the technology safe, then the technology is flawed.

I really think very few developers bother to check fingerprints.

In 2019 I struggled to confirm the SSH fingerprint when connecting to an Ubuntu VM on Amazon EC2. [0] My local machine was running Windows, and I was using PuTTY as my SSH client. Naturally I turned to ServerFault, the relevant sibling of StackOverflow. I was surprised to see that although a similar question had already been asked there, it wasn't clear how I should proceed.

The answer turned out to be pretty non-obvious. The root of the issue was that PuTTY was using an old fingerprint format, different from the one used by Ubuntu. This meant the fingerprint shown in the EC2 instance system log differed from the one shown by PuTTY.

Which seems more likely?

1. Most PuTTY users insist on checking SSH fingerprints, but are smart enough to figure out the proper solution

2. Few developers use PuTTY in combination with EC2

3. Almost no one bothers to check SSH fingerprints

(I believe the particular issue no longer arises as PuTTY has been updated to use the proper fingerprint format. Also, in EC2 you can now bring up a command-line session in the browser, so you can grab the instance's public key that way. I haven't checked recently to confirm, but I believe you still need to look in the instance's system log to dig out the fingerprint - Amazon don't bother to show it anywhere convenient in the web UI.)

[0] https://serverfault.com/q/996828

Simply connect the first time from a known-secure connection. If your laptop is compromised you're screwed anyway.

And store the keys on a yubikey (OpenPGP or more modern Fido2) so they can't be exfiltrated. A huge benefit over a password.

And if you really want, SSH certificates are a thing too.

> Simply connect the first time from a known-secure connection.

No, that's not a solution. The point is to treat the Internet as an untrusted network.

Ah yes but I mean the first time I don't connect to the internet or even VPN. I just connect to my git server on the local LAN.

But good point, as GitHub Cloud is not local. In that case I would verify the key indeed.

I don't think I'd use github for stuff that needs to stay private though. At work we have a self-hosted internal GitHub enterprise server for all closed source projects.

Reply on news.ycombinator.com