There seems to be confusion about the purpose of one-time authentication; the purpose is to protect against key leaks after the key has been used. For instance, suppose I want to SSH to my machine from an Internet cafe but am concerned the key will eventually found by someone after me.
One of the key benefits of asymmetric crypto is that your private portion isn't sent over the wire to authenticate, so it doesn't matter if you're using the key from an internet cafe or the NSA headquarters or your bomb shelter in the hills, your risk of the key being compromised while it's being transmitted over the wire is roughly the same: nil.
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.
Interesting, but unnecessary. First, if a private key is protected with a passphrase with sufficient entropy to withstand a sophisticated attack, then even if the key is on a USB thumb drive, access to the remote system where the public portion is installed is not compromised.
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.
This is a neat hack, but beyond that, I'm not sure what the practical usage is.
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!"
This is a neat idea, and I like innovative sound to it.
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.)
(disclaimer, i'm the co-founder of ScaleFT, a startup building products in this space: https://www.scaleft.com )
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.
Can you explain on how it (new key for every use) could work? If you already have a system (e.g. similar to the current CA system) to tell the remote server to allow a newly generated key in, what purpose does the key serve here at all?
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.
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.
> Can you explain on how it (new key for every use) could work? If you already have a system (e.g. similar to the current CA system) to tell the remote server to allow a newly generated key in, what purpose does the key serve here at all?
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.
> Key files encrypted with passwords are weak because an attacker who compromises the key file can then crack the password offline.
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.
Well considering how obscure the software is that implements it now, I can understand why you'd assume that.
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.
I think the "untrusted system" in question is the system you're logging on from, because that's the only place where the private key could be compromised. I guess the idea is something like, you have a desperate need to log in to a server but the only computer you have physical access to is a machine you don't control (in an internet cafe, say). So you keep your one-time SSH key on a flash drive, use that key on the untrusted machine to log into your server, and you don't have to worry about the untrusted machine keeping a copy of your key (because that key is no longer valid). On the other hand, you do still have to worry about the untrusted machine injecting malicious commands into your session (including, possibly, malicious commands which would allow the attacker to log in to the server as you again in the future).
One application I can think of for this is to have it as part of your "self-destruct" script to move files to a safe location and not possess the knowledge to access them until either you are safe or at a planned later date.
I'm not sure I get it. Looks like the idea is to protect form private key compromise. In which case why is having N instead of one private keys sitting in the same directory more safe? It's not that you are more likely to leak the used ones...
If this did automatic key rotation, it might be quite useful!
I am with you here. It sounds like the security benefit is the key rotation, which IMHO shouldn't have to be done every single time... If this is what the author meant, then he would have written "key rotation" somewhere in the description?!
Another way to secure the authentication is to use a One Time Password to authenticate.
What would prevent the user from simply adding another key once they are logged in for the next time or disabling the script. '~/.ssh/authorized_keys' can be can be read and modified by the user which is currently logged in...
The idea behind this initially was to have 1 key available on say, a flash drive, as a last-resort option for remote logins. This way, even if the key is stolen, it can't be used.
That's what I also thought. But wouldn't it be possible to change the ownership of the authorized_keys file to root? Otherwise maybe am backup of the authorized_keys file and rollback after logout would be an option.
I don't think you have to sacrifice a meaningful key comment to make this work; "MYMH_user_DONOTMODIFYTHISCOMMENT_onetime0" is already on the key's line as part of the sed command that deletes the line with "MYMH_user_DONOTMODIFYTHISCOMMENT_onetime0"
SSH in fact already has support for one time passwords: skey. See http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...