

One-Time SSH Keys - theunamedguy
http://fwei.ml/onetime-ssh-keys.html

======
DblPlusUngood
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.

SSH in fact already has support for one time passwords: skey. See
[http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/...](http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-
current/man1/otp-md5.1?query=skey&sec=1)

~~~
nadams
Google also created a PAM module for OTP [1].

[1] [https://github.com/google/google-
authenticator](https://github.com/google/google-authenticator)

~~~
TD-Linux
There's one for Yubikeys too, which I like because there's no battery to die.

------
atoponce
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.

~~~
hobarrera
This is for usage on untrusted systems. Both keystrokes and the key can be
considered compromised once used there.

------
bascule
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!"

~~~
gkop
> After all, you're giving them remote code execution.

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 :)

------
dantillberg
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.)

~~~
pquerna
(disclaimer, i'm the co-founder of ScaleFT, a startup building products in
this space: [https://www.scaleft.com](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.

~~~
skarap
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.

~~~
russell_h
Co-founder of ScaleFT here.

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

~~~
skarap
Did some reading on ScaleFT website.

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.

------
skarap
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!

~~~
matthiasb
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.

------
Gladdyu
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...

~~~
wtf_srsly
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.

------
tangent128
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"

~~~
theunamedguy
I didn't think of that. Thanks for pointing that out.

------
mykhal
an attacker might already have stolen his keys (why only one?), because the
script checksums do not match :)

~~~
theunamedguy
Fixed ;)

