On Mon, 2007-04-23 at 21:17 +0200, Rico Secada wrote: > On Mon, 23 Apr 2007 13:52:58 -0400 > Greg Folkert <greg@gregfolkert.net> wrote: > > On Mon, 2007-04-23 at 19:39 +0200, Rico Secada wrote: > > > On Mon, 23 Apr 2007 11:26:42 -0400 > > > Greg Folkert <greg@gregfolkert.net> wrote: > > > > > About the union thing I first thought of somehow union mouting all the > > > > > different home directories on a single machine which then serves as > > > > > the access point, but I am affraid if that particular machine crashes, > > > > > then no one can get to their files. > > > > > > > > > > Good ideas and experiences are greatly appreciated! > > > > > > > > Lookup sshfs (or shfs as it is commonly know) it is completely at the > > > > whim of the user. They use an existing well known, well vetted daemon > > > > (openssh-server) and in a local environment (meaning no slow links) with > > > > 100Mbit/sec, I get nearly line speed transfer rates (100Mbit/sec == > > > > 11MByte/sec). > > > > > > > > Though you will need to beef up end user knowledge about strong > > > > passwords and key-auth only authentication, it'll more than makeup for > > > > the traveling or remote user. > > > > > > > > I can say that sshfs is probably the singe best thing I've seen come > > > > along in a long time. Mainly because, if you already have established > > > > good SSH practices, there is really no additional server-side setup you > > > > need to use. > > > > > > Thank you very much for your reply Greg. This is a very good solution > > > but it does provide one obstacle since users do not have SSH access to > > > the servers. If I where to use this solutuion I somehow need to jail > > > the users to their home directories. As far as I know its not possible > > > with SSH. > > > > Why would you need to jail them? > > > > With properly setup homedirs (chmod 0700) nothing needs to be worried > > about as far as seeing other peoples stuff. And as long as they are only > > users, no other groups besides their own group. There is no need to > > worry. For example: > > > > username: joe UID=1110 GID=1110 > > > > No other membership in any additional group. Only can see his stuff > > period. > > > > Infact, it is better than nfs or cifs in regards to security. EVERYTHING > > is in userland and only allows them access to their own stuff on the > > server... even IF they ssh in. > > Thank you very much for your replys Greg! > > What about them poking around on the server setup? If they ssh in, > they can poke around, but does this pose a risk? Them looking around > in /etc or perhaps other places. And again what commands can they use > in this situation. The stuff that really matters they won't be able to read. Remember, *NIX in general has been allowing login via telnet and ssh and other means for MANY MANY years. So what if the can read the "/etc/passwd" file... they won't see any password hash in there unless you specifically allow it, (hasn't been default for years in most Linux distros). Also, if they aren't part of any groups beside their own, they wouldn't be likely to read many things and definitely wouldn't be able to read logs or privileged files. Any private key or things like /etc/shadow are not readable by the general populace on a machine. /etc/ssh/ssh_config is readable but things like /etc/ssh/ssh_host_*_key are not. What is the real worry here? Crackers? If your users are crackers they shouldn't be on a remote plan period. What it really comes down to is that as configured, Debian /etc/ directory is very well setup to protect against the casual cracker. Nothing is safe from the determined cracker. If they are untrustable, just mounting a directory at all over the Internet in the first place would be a bad idea if your users were indeed malicious. Viewing configs is not a criminal offense, though it gives away minor details. The major details are well know in anycase, that is unless you have completely re-compiled and changed default locations for things, this is a lot of work and removes any kind of security support from your distribution, especially if it were RedHat. Your worries are well founded in paranoia and some facts, but overall your mistrust of your users is misplaced. You need to enable them not keep them from *POSSIBLY* taking down a server... which would cost them their job and possibly incur jail time and punitive damages. To do this properly, make sure you do "key authentication only" this will eliminate "weak" password problems. Plus it'll nearly 100% guarantee that brute force guessers will fail. On other technique is treating ssh like rsh, rsh only allows certain things and you can do a similar setup with ssh. This may reduce your concern. Remember sshfs is encrypted both ways, so you need not worry about plain text. I have been administrating *NIX machines for years, I have even done it on "Higher Education" machines. Very few problems arose out of being able to read stuff in /etc/ most of it was weak passwords on telnet or when using ssh. The first thing I did was enforce 8 character passwords as the minimum with at least one capital, one number and one punctuation character. That whole problem will be eliminated if you disable "interactive" login and go straight key-based only. -- greg, greg@gregfolkert.net Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup
Attachment:
signature.asc
Description: This is a digitally signed message part