Sftp-Only User Accounts
Setting up users with very limited access to systems -- nothing more than they need, used to be a little tricky. You could create a specialized environment, chain the visitor to his home directory and do a lot of testing to be sure that your limits were strictly enforced. Limiting a user to only being able to move files to and from your system with sftp is surprisingly simple.
The first thing you need to do is find the sftp-server executable on your system. Let's say the file is /usr/local/libexec/sftp-server. Next, create your new user's account using this file as the user's shell:
# grep sftponly /etc/passwd sftponly:x:9042:8080:sftp-only:/home/sftponly:/usr/local/libexec/sftp-server
If this is the first user to be set up with access limited to sftp, you will also need to add your sftp-server executable to the list of valid shells. You can easily add the file to the /etc/shells file like this:
echo "/usr/local/libexec/sftp-server" >> /etc/shells
At this point, you can test the account using sftp.
# sftp visitor@localhost Connecting to localhost... visitor@localhost's password: sftp> ls sftp> put test Uploading test to /home/visitor/test test 100% 415 0.4KB/s 00:00 sftp> ls test sftp> bye
Anyone used to ftp should have no trouble using sftp. The security advantages are considerable. All data passing back and forth between the server and the sftp client are encrypted.
If your new user is uploading and downloading files from his Windows, Linux or Mac OS X desktop and wants a nicer interface for uploading and downloading files, introduce him to FileZilla. To use sftp with FileZilla, all he has to do is put "22" into the Port: field in the window's header or "sftp://" ahead of the server's name in the Host: field.
This setup provides sftp-only access, but does not restrict these users to their home directories, so don't count on this as a solution for managing untrusted visitors. If you need to restrict your new user to his home directory as well as to only using sftp, you will need a modified sftp-server that adds a chroot function.
Sign up for ITworld's Daily newsletter
Follow ITworld on Twitter @IT_world
jfruh
Apple syncing patent can't come soon enough
pasmith
New Twitter features borrow from 3rd party clients
Esther Schindler
Open Source Changes the Software Acquisition Process
mikelgan
How to set up continuous podcast play on the new iTunes
David Strom
Five important Windows 7 mobility features
sjvn
Guard your Wi-Fi for your own sake
Sandra Henry-Stocker
Grepping on Whole Words
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.













Password change
We use this solution at on our solaris boxes. The problem is, that the users can't change their own password.Do you have maybe a tipp for it?
Sftp-Only User Accounts
Anonymous-Don't think there is a way, with sftp-only, to let a user change his password. However, I think the following would accomplish want you want to do, as long as you have access to the keys (I have not actually tried it). But OpenSSH allows the sysadmin to restrict the commands a user has access to. So I think you can alter the authorized_keys file to say something like the following:
command="/usr/sbin/passwd" ssh-rsa XXXXXX...
When the user ssh's into the machine, all he or she can do is run the passwd command. Unfortunately, if he tries to run another command, it will respond with the passwd prompt, which is probably undesirable, but as best I know that's the way it is.
no need to patch server to chroot sftp server
Since OpenSSH 4.9 (or OpenSSH 4.8 - OpenBSD 4.3 only)It's called "internal-sftp" command.
(I've made a short "historical" note on this: http://zhmark.livejournal.com/1167.html)