33 ms·

I'd generally recommend HTTPS, simply because most developers cannot be trusted to manually verify SSH public keys/fingerprints. Most will blindly approve whate

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.

mariocesar 2y ago
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.
- dangsux 2y ago
  [flagged]
  - MaxBarraclough 2y ago
    > There is a reason github’s ui defaults to clone over ssh which is missed by you. I think you meant HTTPS here?
    - dangsux 2y ago
      [dead]
  - frizlab 2y ago
    Acknowledging I’m not a casual computer user, I personally find https being the unnecessary friction (must [learn to +] setup setting user/password for https, username/password do not work for https because 2FA, etc.). With ssh I upload my key and I’m done.
    - MaxBarraclough 2y ago
      > With ssh I upload my key and I’m done. Not quite. Hopefully you also manually check the host's SSH fingerprint.
      - frizlab 2y ago
        Yes. Still more convenient than the username/password/token dance IMHO.
- redserk 2y ago
  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”
  - mariocesar 2y ago
    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.
- cedws 2y ago
  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.
- MaxBarraclough 2y ago
  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 https://serverfault.com/q/996828
graemep 2y ago
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.
- NegativeK 2y ago
  > 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.
chongli 2y ago
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.
- pxc 2y ago
  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.
- MaxBarraclough 2y ago
  > 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-our-rsa-ssh-host-key/ https://github.blog/news-insights/company-news/we-updated-ou... [1] https://bitbucket.org/blog/ssh-host-key-changes https://bitbucket.org/blog/ssh-host-key-changes
teeray 2y ago
PSA that Github publishes their fingerprints here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints 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).
wkat4242 2y ago
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.
- MaxBarraclough 2y ago
  > 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.
  - wkat4242 2y ago
    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.

mariocesar 2y ago

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.

dangsux 2y ago
[flagged]
- MaxBarraclough 2y ago
  > There is a reason github’s ui defaults to clone over ssh which is missed by you. I think you meant HTTPS here?
  - dangsux 2y ago
    [dead]
- frizlab 2y ago
  Acknowledging I’m not a casual computer user, I personally find https being the unnecessary friction (must [learn to +] setup setting user/password for https, username/password do not work for https because 2FA, etc.). With ssh I upload my key and I’m done.
  - MaxBarraclough 2y ago
    > With ssh I upload my key and I’m done. Not quite. Hopefully you also manually check the host's SSH fingerprint.
    - frizlab 2y ago
      Yes. Still more convenient than the username/password/token dance IMHO.
redserk 2y ago
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”
- mariocesar 2y ago
  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.
cedws 2y ago
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.
MaxBarraclough 2y ago
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 https://serverfault.com/q/996828

graemep 2y ago

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.

NegativeK 2y ago
> 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.

chongli 2y ago

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.

pxc 2y ago
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.
MaxBarraclough 2y ago
> 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-our-rsa-ssh-host-key/ https://github.blog/news-insights/company-news/we-updated-ou... [1] https://bitbucket.org/blog/ssh-host-key-changes https://bitbucket.org/blog/ssh-host-key-changes

teeray 2y ago

PSA that Github publishes their fingerprints here: https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints 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).

wkat4242 2y ago

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.

MaxBarraclough 2y ago
> 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.
- wkat4242 2y ago
  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.