From 5b010b6e9eabf68d000aed71a6affd08800c8902 Mon Sep 17 00:00:00 2001 From: Elijah Cohen Date: Tue, 26 Apr 2022 00:45:05 -0500 Subject: [PATCH 1/1] first ed. --- README.md | 18 ++++++++++++++++++ singe_use_add_key.sh | 16 ++++++++++++++++ 2 files changed, 34 insertions(+) create mode 100644 README.md create mode 100755 singe_use_add_key.sh diff --git a/README.md b/README.md new file mode 100644 index 0000000..821be2f --- /dev/null +++ b/README.md @@ -0,0 +1,18 @@ + +SINGLE-USE SSH KEYS + +Ever wanted a way to get into a server exactly once? Want a backup key with little margin for error? Look no further! + +This simple script will take any public-key on your server and enable it as an SSH key that can be used only once. This works by putting an entry in your `~/.ssh/authorized_keys` which has a command that deletes the entry from itself before dropping the user into their login shell. It's a simple and effective system. + +The only real requirement to use this as intended is that your login shell should be able to take `--login` as an argument. + +To add a key, just run the script with your public key file as the only argument, like `./single_use_add_key.sh .pub`. Your file must be a typical `ssh-keygen` key. This adds the key (and its removal functionality) to your `authorized-keys`, and you use your private key as you would use any other ssh private key. + +Other than the mostly inane uses detailed above, this serves as a nice system to allow an action do be done precisely once per key. You can edit the script and replace `\$SHELL --login` with a command of your choosing. Perhaps you want to print a message once, perhaps you want to allow someone to run a command a set number of times (so you just generate that set number of keys). There are a wide variety of things one could do with this, from practical applications to practical jokes to works of art to single-use passes. + + +There is the potential for a timing issue, if two people attempt to use the same certificate at the same time, then it's somewhat possible that both might be able to get in. I've attempted to alleviate this a little in the code, but the possibility remains, and I don't want to take more extreme or restrictive measures at this point. + + + diff --git a/singe_use_add_key.sh b/singe_use_add_key.sh new file mode 100755 index 0000000..89b38e5 --- /dev/null +++ b/singe_use_add_key.sh @@ -0,0 +1,16 @@ +#!/bin/sh + +if [ "$#" -ne 1 ] || ! [ -f "$1" ]; then + echo "Usage: $0 " + exit 1 +fi + +KEYSTR=$(cat $1 | awk '{print $2}') + +COMMAND="if [ \$(grep '$KEYSTR' ~/.ssh/authorized_keys | wc -l) -eq 0 ]; then echo 'no go'; exit 1; fi; sed -i '\|$KEYSTR|d' ~/.ssh/authorized_keys; \$SHELL --login" + +ENTRY="command=\"$COMMAND\" $(cat $1)" + +echo $ENTRY >> ~/.ssh/authorized_keys + +echo "added key as single-use" -- 2.39.2