However, this doesn't work well with git submodules, because then everyone cloning the repo must recreate this config.
(Just something to be aware of.)
The custom hostname will be replaced transparantly for you and won't need to make it into gitmodules.
# ~/.config/git/config
# Only for single user/org
[url "git@github_ssh:foo"]
insteadOf = "git@github.com:foo"
# all the things
[url "git@github_ssh"]
insteadOf = "git@github.com"
Similar pattern if you want to force-use ssh instead of https or vice-versa.
You can't clone a public repo over SSH without having authenticated keys set up. Somewhat annoying on servers that you forgot/don't want to use agent forwarding on.
You can set up anonymous SSH access. It is just that for some reason the big "hubs" do not do so. See for example the instructions that come with gotsh(1):
From your link, literally, both HTTPS and SSH have pros and cons! You make it look like SSH only has cons and HTTPS only has pros; that’s borderline dishonest.
I also used to think this, then I realised https has far better performance, particularly for high latency connections.
A big repo clone from Github to here in Australia takes about half the time over https when compared with ssh. I'm not sure if github has region-located repos.
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.
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.
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.).
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.)
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.
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).
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.
Also, if you're on a corporate network and start pushing ssh through 443, a competent security team should check in on you to make sure things are okay.
It’s by design. There was some cyber practice doc years ago calling out how outbound ssh is a security risk because it can’t be monitored. And they’re afraid people will steal data and send it out without network security knowing.
I hated the policy because I loved outbound ssh tunnels to get around blocked websites (ie, no gmail). But I kind of understand it because dumb people will do dumb things and they can’t differentiate people who will use appropriate judgement.
But I’ve found that eventually every large org I’ve worked for ends up blocking ssh.
If it’s your home ISP doing this, you just need to call and ask for them to remove the restriction. Obviously not likely to work if this is a corporate network.
What's funniest without any doubt is that passwords and similar shared secret systems have worse usability and worse security.
They're a classic "Worse is better" like C where their principle advantage is simplicity of implementation. Sure, they're terrible, but look easy it was!
I know right? Stupid facts, going around disagreeing with your intuitions.
How can shared secrets be a bad idea? I mean, it was considered pretty good a thousand years ago, can technology really have improved since then? [Hint: yes, drastically]
56 comments
[ 4.7 ms ] story [ 125 ms ] threadWhy use git over https then?
The custom hostname will be replaced transparantly for you and won't need to make it into gitmodules.
Similar pattern if you want to force-use ssh instead of https or vice-versa.https://www.gameoftrees.org/gotsh.1.html
Obviously not a good idea for repositories that you want to keep private. But it is odd to me how rare it is for public repositories.
Also, cloning private repo via http is a pain, when MFA is involved
Briefly, HTTP is more flexible. For authentication, you could use passwords or OAuth.
A big repo clone from Github to here in Australia takes about half the time over https when compared with ssh. I'm not sure if github has region-located repos.
Somewhat related: SourceHut blog post on them optimising Git operations over SSH: https://sourcehut.org/blog/2019-11-22-what-happens-on-git-pu...
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.
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 think you meant HTTPS here?
With ssh I upload my key and I’m done.
Not quite. Hopefully you also manually check the host's SSH fingerprint.
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”
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.
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
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.
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.
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.
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
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).
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.
No, that's not a solution. The point is to treat the Internet as an untrusted network.
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.
I couldn't imagine living without ssh.
I hated the policy because I loved outbound ssh tunnels to get around blocked websites (ie, no gmail). But I kind of understand it because dumb people will do dumb things and they can’t differentiate people who will use appropriate judgement.
But I’ve found that eventually every large org I’ve worked for ends up blocking ssh.
If it doesn't require shared secrets, this isn't scary, the git mechanism works just fine.
that's ... one of the dumbest thing I've ever read
They're a classic "Worse is better" like C where their principle advantage is simplicity of implementation. Sure, they're terrible, but look easy it was!
How can shared secrets be a bad idea? I mean, it was considered pretty good a thousand years ago, can technology really have improved since then? [Hint: yes, drastically]
rm -rf /usr/local/libexec/git-core/git-credential-cache*