Hi. The attached patch[0] (which I've admittedly haven't had time just now to check whether it actually works - but it should at least serve as a discussion base) would make sshd pass a 2nd argument to the authorized keys command. The idea is, as the commit message says, that programs like Gitolite, which my have many (up to the range of thousands) keys per single username (for example “git”) can use that fingerprint in order to efficiently retrieve that matching key(s) from a database (or something like that). Right now, such programs suffer quite a lot, when sshd linearly parses an authorized_keys file with a gazillion of entries. Most likely, legacy authorized keys commands shouldn’t be affected by this, at least unless they check for a maximum number for command arguments. Right now I'm just a bit worried about two issues: - using MD5,... which may be appropriate for the idea from above, but people might also use the whole thing in a different (security related) way... and there MD5 should be a no-go. - not encoding the presented hash alog (which makes the whole thing unchangeable forever i.e. perhaps one should rather use pass arguments like johndoe -md5=e702125c0dfcb8801a07ddd8ef719ab8 or johndoe md5 e702125c0dfcb8801a07ddd8ef719ab8 (even though I'd probably tend to the former) What do you guys think? Cheers, Chris. [0] Based on an idea by Sitaram Chamarty and a patch from Jason A. Donenfeld.
From 2d657e93989d28c4c114dd2646d412a77ba39755 Mon Sep 17 00:00:00 2001
From: Christoph Anton Mitterer <mail@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Date: Sat, 28 Feb 2015 05:49:15 +0100
Subject: [PATCH] pass key fingerprint to authorized keys command
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In addition to the authenticating username, also pass the MD5 fingerprint of the
client’s SSH key to the authorized keys command.
The idea is that programs like Gitolite, which my have many (up to the range of
thousands) keys per single username (for example “git”) can use that fingerprint
in order to efficiently retrieve that matching key(s) from a database (or
something like that).
Most likely, legacy authorized keys commands shouldn’t be affected by this, at
least unless they check for a maximum number for command arguments.
Signed-off-by: Christoph Anton Mitterer <mail@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
---
auth2-pubkey.c | 3 ++-
sshd_config.5 | 5 +++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/auth2-pubkey.c b/auth2-pubkey.c
index d943efa..bb5b008 100644
--- a/auth2-pubkey.c
+++ b/auth2-pubkey.c
@@ -622,7 +622,8 @@ user_key_command_allowed2(struct passwd *user_pw, Key *key)
}
execl(options.authorized_keys_command,
- options.authorized_keys_command, user_pw->pw_name, NULL);
+ options.authorized_keys_command, user_pw->pw_name,
+ sshkey_fingerprint(key, SSH_DIGEST_MD5, SSH_FP_HEX), NULL);
error("AuthorizedKeysCommand %s exec failed: %s",
options.authorized_keys_command, strerror(errno));
diff --git a/sshd_config.5 b/sshd_config.5
index 6dce0c7..b414774 100644
--- a/sshd_config.5
+++ b/sshd_config.5
@@ -231,8 +231,9 @@ of a single authentication method is sufficient.
.It Cm AuthorizedKeysCommand
Specifies a program to be used to look up the user's public keys.
The program must be owned by root and not writable by group or others.
-It will be invoked with a single argument of the username
-being authenticated, and should produce on standard output zero or
+It will be invoked with the username being authenticated as first argument,
+the MD5 fingerprint of the key presented by the client as second argument,
+and should produce on standard output zero or
more lines of authorized_keys output (see AUTHORIZED_KEYS in
.Xr sshd 8 ) .
If a key supplied by AuthorizedKeysCommand does not successfully authenticate
--
2.1.4
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
