One-Time SSH Keys

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.<p>SSH in fact already has support for one time passwords: skey. See <a href="http:&#x2F;&#x2F;www.openbsd.org&#x2F;cgi-bin&#x2F;man.cgi&#x2F;OpenBSD-current&#x2F;man1&#x2F;otp-md5.1?query=skey&amp;sec=1" rel="nofollow">http:&#x2F;&#x2F;www.openbsd.org&#x2F;cgi-bin&#x2F;man.cgi&#x2F;OpenBSD-current&#x2F;man1&#x2F;...</a>

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.<p>Second, if the key was unprotected on a USB drive, and the drive is lost, what&#x27;s stopping you from taking the key out of the authorized_keys file on the remote server?<p>Lastly, if there is a need for a single use SSH key, then it should be indicated as such in the key&#x27;s comment, so when the scenario is over, it&#x27;s easily identified as which key it is.<p>I guess I don&#x27;t understand the practicality of this script, let alone one-time SSH keys.

This is a neat hack, but beyond that, I&#x27;m not sure what the practical usage is.<p>If &#x27;.authorized_keys` can be modified by the user, then one-time access is easily escalated to many-time access.<p>If not, they can still leave a process running on the host to obtain access later. After all, you&#x27;re giving them remote code execution.<p>You could try to prevent them from obtaining shell access and use SSH as an encrypted transport and AuthN system. That&#x27;s not really discussed in the post at all.<p>This post is really more like &quot;Look ma, .authorized_keys can run commands!&quot;

This is a neat idea, and I like innovative sound to it.<p>But what happens if the key is compromised during this single use? Isn&#x27;t that just as problematic from a security perspective?<p>I&#x27;m guessing by &quot;untrusted system&quot; that we&#x27;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.<p>Or put another way: what attack vectors are prevented&#x2F;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?)<p>(side note: I believe that if you don&#x27;t verify host keys, then SSH is completely, 100% useless against MITM&#x2F;proxy attacks, whether you allow the key to be used 1 or infinite times. Please correct me if I&#x27;m wrong on that.)

I&#x27;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&#x27;s not that you are more likely to leak the used ones...<p>If this did automatic key rotation, it might be quite useful!

What would prevent the user from simply adding another key once they are logged in for the next time or disabling the script. &#x27;~&#x2F;.ssh&#x2F;authorized_keys&#x27; can be can be read and modified by the user which is currently logged in...

I don&#x27;t think you have to sacrifice a meaningful key comment to make this work; &quot;MYMH_user_DONOTMODIFYTHISCOMMENT_onetime0&quot; is already on the key&#x27;s line as part of the sed command that deletes the line with &quot;MYMH_user_DONOTMODIFYTHISCOMMENT_onetime0&quot;

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