Re[2]: [SAGE] The danger of SSH keys..

["Dustin Puryear" <dustin@puryear-it.com>]

And to me, that is where strength should be added: At the server. The
main issue I am raising with keys is that the security of the key is
entirely a client issue. There is no way for me to really enforce
anything on the server.

With keys, I want the ability to:

1. Expire keys at the server, even if that means rotating the public
key out of authorized_keys2 (this could be done today using scripts).

2. Remove public keys when an employee is fired. Really, this can all
be handled now via homedirs, requiring sudo, and protecting my root
authorized_keys2.

3. Require private keys to have strong passwords (no realistic way to
enforce this).

With this, I think the strength in using SSH keys could be
dramatically increased.

---
Puryear Information Technology, LLC
Baton Rouge, LA * 225-706-8414
http://www.puryear-it.com

Author:
  "Best Practices for Managing Linux and UNIX Servers"
  "Spam Fighting and Email Security in the 21st Century"

Download your free copies:
  http://www.puryear-it.com/publications.htm


Monday, January 22, 2007, 12:47:08 PM, you wrote:

> Hal Pomeranz wrote:
>>> If you're not up to coding it yourself you could submit a feature 
>>> request (with associated offer to fund development if you really want 
>>> it). If the OpenSSH folks added it themselves it could likely be managed 
>>> via an associated config option.
>>>     
>>
>> The problem with doing this is a config option is that any such checks
>> would of course have to be implemented in the client binaries (including
>> ssh-keygen).  The problem is that there's no way to enforce global 
>> administrative policies on the client side, because the user can always
>> override configuration settings in ssh_config with command-line options.
>> It's similar to the problem of trying to enforce StrictHostKeyChecking
>> across an entire site.
>>
>>   
> True, and it doesn't get around people installing their own client binaries.

> I wonder if there'd be value in extending the SSH protocol to also allow
> encrypting the public key with a passphrase, which could then be 
> validated for length on the server during initial handshake.

> Bryan