No. But it eases "man in the middle" attacks (someone impersonating the host you think you're connecting to, with that key).
Still, if someone puts your pub key in an authorized_keys of a malicious host, and then manipulates your DNS or ARP to conduct you to such host, you should get some SSH warnings about the host fingerprint, etc.
And still, if you're using a dedicated key, the only possible attack could be to make you commit your repo changes, to the malicious machine instead of to github.
Yes, but they will have to un-pin the (now compromised) key if they want to continue using Github.
Any compromise would have to isolate them from the "real" Github hosts from today onwards, i.e. plausibly MITM them continuously, or they would just switch to the rotated key to be able to continue working. At least in OpenSSH, this means replacing the compromised trusted key, as there can only be one per host (or even IP in the default configuration).
This is still very bad, but much less catastrophic than e.g. a world in which `.ssh/known_hosts` allows multiple entries, in which case you'd really have a sustained compromise of most clients.
Though for new hosts people often don't verify the initial host key at all, just blindly accepting it, so that would be an extra risk vector.
Heck, I'm sure many don't bother verifying a new key when they get the warning, instead just removing the old from .ssh/known_hosts (or equivalent) to quiet the complaining! Though to be honest, with that security posture nothing is going to save them and our efforts are better spent securing others! I know at least one of our clients has automated systems that ignore key changes, because we once had a temporary config cockup that sent some connections to a host with the wrong key and some data was received there without any reported issues…
Not really weird, no. The host key needs to be used every time someone establishes a SSH connection to Github. HSMs can't handle that volume of requests.
Given that the key is extremely long lived, this has unfortunate implications: If any of these servers is compromised, or decides to go randomly spewing memory content because of a bitflip, or screws up the nonce on a DSA/ECDSA operation, the key can be compromised. This is hard to exploit if you're a random person, but for a global adversary that collects internet traffic at scale (e.g. NSA), it's feasible and I would be surprised if they weren't exploiting such issues. They were collecting HTTPS handshakes for a reason.
If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to.
Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to.
My "github" key only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers.
I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem.
As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.
You certainly can, it's almost certainly unnecessary though. SSH keys are not like passwords, compromise of a server with your pubkey in no way effects the security of your private key. Many people will post pubkeys online so they're easy to add to new servers.
Only if you have an out-of-band way of verifying SSH keys. In my experience, 9 out of 10 times that doesn't happen and people just accept a changed SSH key.
> This ensures the key is never transferred somewhere it can be copied.
But it does not ensure that the computer will add another entry to the authorized_keys file in the host as soon as you access it. Or install a rootkit there with another kind of backdoor.
If you don't trust your computer, don't give it access to your servers.
There is technically one minor one, which really isn't one - but you should be aware of.
Someone can take your authorized keys and add them to a box they control, and trick you into logging in.
However, this would trigger the "new host" warning SSH gives you, and you can minimize this by minimizing which hosts you allow your private keys to be used on.
And if someone is so actively trying to attack you they probably have more direct methods available.
Depends on the type and number of bits in the key.
If you create an ssh key that is already broken (say you managed to generate a... 512 byte RSA key), then an attacker would know what key he needs to generate before he attempts to authenticate with your server (or github).
We can even verify that it's an RSA key with 4096... exactly what you could (should?) use to generate SSH keys. Effectively posting your public ssh key in the wild is as safe as debian posting their public signing key :)
Not just that. Even if you don't make that mistake, having servers ssh into other hosts and leaving keys on them for this purpose means if one machine is compromised, others can be too. And they can use known_hosts to discover which ones.
But the private key is (of course) never sent to GitHub, so it's hard for me to imagine what kind of vuln this would help with. I can think of a few, but they're odd:
1. Some sort of remote memory leak that leaks the current private key, I guess.
2. Some sort of relay attack where you can impersonate the legit host.
In both of these cases, it seems like at a minimum you would need to, on the client, set up an ssh config that limits each identity to each host so as to prevent the client from trying each key in sequence (and thus potentially exposing it). That's a huge hassle!
So I guess tl;dr: I can think of a few cases where this might be useful, but if you're always SSH'ing from the same laptop, this step can probably be pretty far down your list of things to do.
No. I said that changing the key, which must happen, will trigger a warning that will scare users away. Which is (partly) why no one uses SSH with non technical populations.
The idea that this gives write access to my SSH keys is still scary. Not that I don't trust your service, but what if somebody attacks it and adds malicious keys?
1. with pubkeyauthentication, you don’t send your private key. Your public key, which is stored on the server, is used to encrypt something. You prove you have the corresponding private key by sending back a decrypted version of the something. Attempting to log in to a server, whether they have zero or more of your public keys poses no risk.
2. You can control which private keys are used for which remote server using .ssh/config. You can look up the man page for more.
3. There is a risk of using ssh-sgent key forwarding that while you are connected to a server with key forwarding turned on, a super user sudo to your user and log in to a second host. This risk can be minimized by only enabling key agent forwarding to hosts you trust and limiting the keys available to each host.
Keys are easily (and persistently) added to ssh-agent, at which point it is easy to forward and will generally silently authorize without any further user interaction. That reduces it to a single factor.
Compare that to a totp challenge or a yubi key plus a password. Having one of them won’t get you the other.
Still, if someone puts your pub key in an authorized_keys of a malicious host, and then manipulates your DNS or ARP to conduct you to such host, you should get some SSH warnings about the host fingerprint, etc.
And still, if you're using a dedicated key, the only possible attack could be to make you commit your repo changes, to the malicious machine instead of to github.
reply