On Sat, 2004-07-24 at 15:07, Kenneth Porter wrote: > The issue here is trust in your "local" users, not ssh itself. Many of the > recent vulnerabilities in the Linux kernel and other packages require that > the attacker be logged in with shell access. If you don't provide shell > access, you can afford to ignore these kinds of vulnerabilities and reduce > the frequency that you patch the server. If you have untrusted shell users > then you need to be much more vigilant, because they can use those > vulnerabilities to escalate their privilege and root your box. > > I use a hosting service that allows ssh, but as a matter of policy they > require that the user submit picture ID before enabling this access. It's a > hassle but I can understand this paranoia, as I operate servers myself. > > You should never use telnet on a public interface. It exposes passwords in > clear text, and that means malicious sniffers could get a shell on your box > using the accounts of your trusted users. But ssh is not a panacea. Like > https (secure http), it protects your users, not the server itself. Very good point. You should also consider implementing chroot to limit what the users that login into your network can do and access. If all they do is change their passwords you should be able to limit them to just that command. I would have to check to see if passwd can be done from a chrooted environment. -- Scot L. Harris webid@xxxxxxxxxx While it may be true that a watched pot never boils, the one you don't keep an eye on can make an awful mess of your stove. -- Edward Stevenson
