 Re: Preventing Auto-Login
On 16 Jul, 09:24, brontolo wrote:
> 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.
Have you successfully used this?
There are plenty of procedures, such as rsync over SSH based backup
procedures and Subversion access, that do require unattended access.
It's the sort of thing that makes me wish that chroot cages had been
properly implemented for OpenSSH 5. (All chroot users having the same,
shared chroot cage is fairly nutty: the paches to support per-user
chroot cages have been around for years, and I'm confused why those
weren't used.)
 |