Todd H. ha scritto:
> c writes:
>
> You are attempting to implement a technical control on a people issue,
> and actually may end up making things less secure in the process. :-)
>
> The good news is that these developers aren't weakening your security,
> more than likely.
>
> Key based auth is actually more secure than password auth as it
> resists brute force attacks much better. If you've checked log files
> for any sshd on the internet, you know that brute force attacks are
> out there in force!
>
> I believe your primary concern should instead be sure that these
> developers have protected their private keys with a passphrase that's
> not trivially broken, and that their keys are not world readable
> (though I'm not sure if openssh will even use such keys).
>
> This brings up the interesting question of whether there are tools to
> audit those.
>
> By the way, I work on a hgihly secured system for a client, and that
> one WONT't allow anything but key based auth. Password based auth is
> disabled by administrative choice. Key based auth is where it's
> at.

You forgot that system password can be locked (even automatically on
expire time) using standard user-management tools.
Public key must be removed or renamed manually.

The problem can be avoided if OpenSSH will implement a feature that
optionally can require _both_ key and password authentication, as Tectia
or F-Secure ssh implementations do.