Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

ssh - chrooting



 This is probably basic, but I have done my RTFM work for the day and 
cannot seem to get past this one. 

We use dropbear client on some remote machines (running very automated 
stuff).  We run ssh on our server and do NOT allow telnet logins (port 
23) nor do we support password authentication per se.  This closes, in 
our view, some commonly exploited security worries. 

Each remote site has a unique RSA certificate and a home directory. 
Each remote site uses dbclient as the transport where dbclient is used 
by scp for getting and putting files in specific subdirectories off the 
home directory on the server. 

By sheer accident (testing by initiating a shell using dbclient) I 
discovered that I could cd /... cd /var/.. etc.  In some cases I could 
even read and write files!!! 

Not what we had intended.  Now we have n number of sites out there, all 
having nice keys into the production server where some hack can do who 
knows what. Scary part is we don't know what the impacts may be, yet. 

My (stupid?) assumption was that a given user logging in via ssh would 
be limited to their /home directory.  Not so.  Apparently any user 
coming in via an ssh certificate assigned to a specific user can still 
grope around, and if files/(directories) have world access, they can play. 

We tried a little trick: rc in the user's home/.ssh directory, containing: 

        /usr/sbin/chroot . 

However it appears chroot cannot be executed by other than.. root! 

So, long-winded, but how might we accomplish the following: 

1. Limit users to their home directory only 
2. Allow users enough access so they can perform scp operations in their 
home directory and subdirectories off of it, and 
3. Allow users to delete a file (after an scp get).  This last one seems 
like it's suited for a shell operation but since the remotes are 
automated, it might be impossible. 

Any unix/linux file system folks out there care to chime in?  Public 
whipping will be tolerated in order that we learn :) 



-- 
This message has been scanned for viruses and 
dangerous content by MailScanner, and is 
believed to be clean. 

_______________________________________________ 
Discuss mailing list 
[hidden email] 
http://lists.blu.org/mailman/listinfo/discuss
 


BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org