Peter Serwe wrote: > >> PermitRootLogin without-password >> AuthorizedKeysFile /just_a_dir/authorized_keys/%u >> PasswordAuthentication no >> UsePAM yes >> >> This will give you control of access if at least the >> /just_a_dir/authorized_keys folder is not writeable for the world >> (the keys need to readable, not writeable for the user that tries to >> log on) > Setting "PermitRootLogin without-password" doesn't help your > authorized_keys issue, doesn't > do anything to make ssh keys work better, and just opens you up to a > whole world of issues in > the event of some sort of a security problem. The reason it's still open for root (with key), is that it's being synced to a remote mirror. Indeed closing the access is always better. > > I personally set "PermitRootLogin no" on anything I allow direct > access from the outside world to. > > Setting the AuthorizedKeysFile to anything other than > ~/.ssh/authorized_keys seems ludicrous > to me as well. It's not like a user can do anything with that file > other than add to it, or steal public > keys from machines that are allowed to login to it without a password, > thereby allowing either > a different machine to log into that machine without a password, or > propagating the machines > your trusted hosts can log into without a password. > > Personally, too much trust is a bad thing. If you need to automate > stuff, do it on locked-down > user accounts and give them permissions to put the stuff where they > need to go, or cron something > to check for the data and move it. Well I like to control what is in the public keys. This way I can limit acces based on IP. Some users only have access to CVS. Theo