5 ms·

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

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

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