One-Time SSH Keys
fwei.ml
fwei.ml
SSH in fact already has support for one time passwords: skey. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
The risk to the private key is that somebody gets access to your system without your knowledge, but since you need a way to auth to the remote system for this script to put the one-time keys there... what stops the attacker from grabbing the not-one-time key or other creds?
If I really wanted some kind of rotating key-based-auth, I'd probably do it via some mechanism where the server pulled valid keys. Offhand, using sshd_config's AuthenticationMethod combined with some GPG signed pubkey lists hosted somewhere, such that it could pull a list of one-time pubkeys and then nix them as they were used.
Upside there: as others have pointed out in this thread, a big issue for this is that a non-root user typically can write to their own .ssh/authorized_keys, negating the "one-time" nature of this access. Moving the pubkey-checking outside of their control would limit that, local priv-esc vulns aside.
Second, if the key was unprotected on a USB drive, and the drive is lost, what's stopping you from taking the key out of the authorized_keys file on the remote server?
Lastly, if there is a need for a single use SSH key, then it should be indicated as such in the key's comment, so when the scenario is over, it's easily identified as which key it is.
I guess I don't understand the practicality of this script, let alone one-time SSH keys.
If '.authorized_keys` can be modified by the user, then one-time access is easily escalated to many-time access.
If not, they can still leave a process running on the host to obtain access later. After all, you're giving them remote code execution.
You could try to prevent them from obtaining shell access and use SSH as an encrypted transport and AuthN system. That's not really discussed in the post at all.
This post is really more like "Look ma, .authorized_keys can run commands!"
I may be wrong, but I believe ssh can be hardened more or less effectively against RCE, and still be of practical use (eg. for file uploads).
Edit: which you sort of say in your own comment - you and I can both imagine interesting uses :)
But what happens if the key is compromised during this single use? Isn't that just as problematic from a security perspective?
I'm guessing by "untrusted system" that we're talking about an SSH host for which you do not already have and verify the SSH host fingerprint (see side note below). And so, for example, you try to connect to that host, but instead your request is MITMed and the attacker has control of your session with that remote host.
Or put another way: what attack vectors are prevented/mitigated by disabling the key on use? (and this is separate from the very inconvenient aspect regarding: how do I connect back to that host after my one session is over?)
(side note: I believe that if you don't verify host keys, then SSH is completely, 100% useless against MITM/proxy attacks, whether you allow the key to be used 1 or infinite times. Please correct me if I'm wrong on that.)
I believe that "ephemeral" or "dynamic" credentials is a concept that is just starting to emerge.
This particular implementation, I don't see what threats it is really stopping.
One question we lead with at ScaleFT is, "How Old should an SSH Key be?". It leads many to admit they have had the same key, across multiple companies, across multiple devices. The threats against that kind of private key are massive, everything from an old corporate backup at a company you don't even work at anymore, to an APT capturing it 3 weeks ago.
Basically using an SSH key, doesn't prove much, except that at any point in time, you had the associated private key. This is a pretty broad attestation of identity -- so generating a key for every use -- and then building in additional attestations of identity (eg, two factor) for the use of that key, is something I think we will see more of in the future.
Also - the encrypted private key is already two-factor authentication - you have the key and you know the encryption password for the key. Is this fact usually ignored by everyone because paswordless keys are that common?
As for the "age" of a key, I totally agree here - using the same key forever and on multiple devices (especially in multiple companies) is asking for trouble. I'm not completely sure what the best practice is, but the user@hostname appended to the end of the public key sort of suggests you are supposed to have a separate key on each host - that's what I do.
It protects against old key compromise. Sometimes the attacker will compromise a key from a week-old backup or because someone forgot to wipe the disk when they replaced a PC. If the key is changed on every use or on a short interval then it will be unusable by the time the attacker learns it.
Of course, that also means a backup of the key will be unusable to the actual user.
> Also - the encrypted private key is already two-factor authentication - you have the key and you know the encryption password for the key. Is this fact usually ignored by everyone because paswordless keys are that common?
Key files encrypted with passwords are weak because an attacker who compromises the key file can then crack the password offline. By contrast, when the password is verified by the remote server, the attacker has to guess passwords online, which is much slower and allows the server to block or rate limit the attacker after too many bad passwords.
If like to see them try with a 18 character long password.
Btw: is there a way to convert a private key to such a format which looks absolutely random (so the attacker can't tell if the decryption worked until they try to use the key)? Though IIRC three are some prime numbers there... Might not work.
With a CA system you still need a key of some sort just due to how it works, but you're right that generating a new one every time isn't as critical because you are authorized by the tuple of (key, certificate). But certificates aren't intended to be treated as secrets, so re-generating the key frequently still adds a lot of value.
Passphrases are a good start towards protecting a key. As an individual, if you use a passphrase, secure your laptop or workstation, and rotate your key frequently (remove the public key everywhere it is trusted) you'll probably be OK. AnthonyMouse is right about the advantages of checking a password server-side though.
Another neat advantage of moving identity verification online is that you can adopt more interesting auth mechanisms and blocking heuristics. Think of all the things that Google et al do to secure logins.
The real take-away here though is that while an individual can do a pretty reasonable job of securing an SSH key if they practice strong discipline[1], the risk for a team of individuals grows with its size. All it takes is for one team member to have their laptop compromised, and the game is over. SSH keys just don't provide a reasonable way to manage, or even assess this risk.
[1] around securing their laptop, using a passphrase, ideally not using ssh-agent, definitely never forwarding ssh-agent, rotating frequently, etc
To be honest - I'm a bit conservative especially when dealing with security. I don't believe you should "put your ssh keys in the cloud" to make them more secure. So I'm somewhat biassed.
Anyway - considering the single developer's laptop, you can't improve much on ssh keys. You might be able to add 2FA using some token. You might also improve the key management software to notify and help rotate keys. "Cloud" based solutions won't add security either - the api keys used to access the service can be compromised as easily.
If we are taking about a company/enterprise, then I'm all for centralized authentication/authorization. But in this case there are a couple of decades old solutions - Kerberos. It won't give you expiring SSH keys, but week give you expiring tickets.
However according to the Fox Technologies Wikipedia Page, BoKS aka KEON includes support for "...SSH protocols: SSH keys generated by FoxT ServerControl, or to re-use existing SSH distributed keys.", and they've had that technology for years.
Trust me - I'm not denigrating what you guys are doing and in fact I look forward to concepts like this found in BoKS making it into wider circulation. Just saying there may be a little prior art, as it were.
If this did automatic key rotation, it might be quite useful!
Another way to secure the authentication is to use a One Time Password to authenticate.