Hacker News new | past | comments | ask | show | jobs | submit login

>Did you check to make sure that the key that popped up was correct, or did you just hit accept?

But if you had the key cached, and it changed, you’d probably freak out.

>This is why signing packages will not be a silver bullet that significantly reduces these kinds of attacks.

You’ve just isolated the impact of these attacks to new installs, how is that not significant?




> But if you had the key cached, and it changed, you’d probably freak out.

Not in the servers-as-cattle age. By default, a rebuilt server will have a new key. Otherwise, you'd have to save the server SSH key in your configuration/build files, and then you've moved what you have to protect to the source control of the servers, and probably exposed that secret key to many more people and developers than you would have done by leaving the key on the server.

Jumping one stratum forward, with hosted k8s you don't even know the host's key; you do everything via HTTPS and the almost globally accepted list of secure CA:s.


Don’t you just use your own SSH CA when you scale up?


Okay, followup question -- when was the last time anyone saw the key change and actually did freak out?

If you're using VMs, keys change all the time. Maybe some people here are good about security and would freak out, but I'm thinking about workplaces I've been at, and that's not a typical attitude for developers that I know. If I set up a VM at work and changed the keys on it, I doubt my coworkers would even ask me about it when they saw the warning.

And I'm literally right there -- they're not going to file a Github issue for a developer they've never met asking why the key changed and then stop working until they get a response.

To push the point even more, how many people on here actually wrote down the SSH fingerprint that they got the first time they connected to a remote machine? When you got a new laptop, did you transfer the keys over, or did you just blindly reconnect to every VM again?

Package managers are meant to help you manage installs on multiple machine, so it's not just the first time you use a package -- it's every time you do a fresh clone the repository, it's every time you throw away your cache and do a new reinstall over the network.

And it's based on this idea that even when doing an update, package managers and developers won't just blindly hit OK if they get a notification that a key changed, which I just don't think is the norm, even in technical circles.


>Okay, followup question -- when was the last time anyone saw the key change and actually did freak out?

Less than a week ago, a server of mine rebooted due to an unannounced power outage. This particular server just stores some backups and didn’t have proper monitoring, I didn’t know it had rebooted. Normally mere unannounced power outages have me shitting bricks, switching hosts or at least extensively verifying the pre-boot environment.

Trying to SSH into the box I received the host key mismatch error because the server boots into dropbear for LUKS. It took me a few minutes to figure out what had happened, but until I did, I definitely fully assumed that my host was up to something really bad.


> Okay, followup question -- when was the last time anyone saw the key change and actually did freak out?

Every time. Well, "freak out" is a strong phrase. But I do check with knowledgeable member of team before continuing.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: