Hi there, We could set AuthorizedKeysCommand script, this will allow only to replace authorized_keys file with keys stored in a database... But why this command is so limited? Why i can't just set a command script which will get a username and public key as arguments and let him do it's own authorization?? I think this will allow for much more powerful tricks. For example do to an database lookup with keys to identify and authorize or deny access and so on... So is this so difficult to do? What do you all think about this? Thanks.
On 01/14/2013 10:36 AM, Katsumoto san wrote:> We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization??It sounds to me like you're proposing a different interface than the current AuthorizedKeysCommand -- the current interface maps quite cleanly to the AuthorizedKeysFile, and can be processed in a similar way by ssh (it's just reading the list of authorized keys from a different kind of file descriptor). What you're proposing sounds rather different (but i agree it could be useful). It's more of a KeyAuthorizationCommand (since it takes a single key and decides whether it is authorized) than an AuthorizedKeysCommand. But note that an ssh client can offer several keys to the ssh server [0] to see which ones might be acceptable. So the command you describe might need to be invoked several times per attempted connection. Maybe you could propose a concrete specification for what you want? How would the public key and user account be structured as arguments to the command?> I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on...Note that the current API can still do a database lookup by the user account, as long as the database is able to enumerate the keys that are acceptable for authorizing access. --dkg [0] https://tools.ietf.org/html/rfc4252#section-7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130114/96a91a7d/attachment-0001.bin>
Seems very useful. Implementation-wise I would not exclude AuthorizedKeysFile if AuthorizedKeysCommand was present, because if script will be connecting to external services which mail fail or hang, one still needs access to machine in case of emergency. In this respect, execution of external command should be time-limited to avoid locking admin out of the system in troubled times. b. On 14 January 2013 16:36, Katsumoto san <shogun147 at gmail.com> wrote:> Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... > > So is this so difficult to do? What do you all think about this? > > Thanks. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
On Mon, Jan 14, 2013 at 09:36:26 -0600, Katsumoto san wrote:> Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited? > > Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on... > > So is this so difficult to do? What do you all think about this? >I believe the intent was to minimize the risks by keeping the implementation simple. However, you can embed some flexibility either in the command which you invoke or, potentiall, in the repository used to store the keys. I don't quite see the advantage of the approach that you are suggesting. Could you elaborate on it a bit? What sort of "tricks" are you thinking of? -- Iain Morgan
On Mon, 14 Jan 2013, Katsumoto san wrote:> Hi there, > > We could set AuthorizedKeysCommand script, this will allow only to replace > authorized_keys file with keys stored in a database... But why this command > is so limited?The output of AuthorizedKeysCommand may contain any directive that is allowed in authorized_keys, so it's actually quite powerful.> Why i can't just set a command script which will get a username and public > key as arguments and let him do it's own authorization?? > I think this will allow for much more powerful tricks. For example do to an > database lookup with keys to identify and authorize or deny access and so > on...You'll have to explain this example more, because it seems to me that this is well within the capabilities of the current AuthorizedKeysCommand. -d