Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is there any way to configure a user on a Linux box (Centos 5.2 in this case) so that they can use scp to retrieve files, but can't actually login to the server using SSH?

share|improve this question
    
I tried setting the login shell to /bin/false, but that just stops scp working altogether. –  DrStalker Nov 12 '09 at 2:55
add comment

8 Answers 8

up vote 21 down vote accepted

rssh (http://pizzashack.org/rssh/) is designed for precisely this purpose.

Since RHEL/CentOS 5.2 doesn't include a package for rssh, you might look here to obtain an RPM: http://dag.wieers.com/rpm/packages/rssh/

share|improve this answer
    
that's awesome - I've been looking for something like this for a while, too –  warren Nov 12 '09 at 4:44
3  
the idea behind rssh is nice, but iirc rssh wasn't exactly a miracle of security in programming terms. A simple google on 'rssh exploit' yields more results than I am comfortable with... –  wzzrd Nov 12 '09 at 7:48
6  
scponly is more or less the same thing as well and apparently less exploits-prone : sublimation.org/scponly/wiki/index.php/Main_Page –  François Feugeas Nov 12 '09 at 10:52
    
scponly appears to have moved to github. The sublimation link is dead. github.com/scponly/scponly/wiki –  spazm Sep 13 '13 at 22:04
add comment

I'm a bit late to the party, however I will suggest you take a look at the ForceCommand directive of OpenSSH.

Subsystem sftp internal-sftp

Match group sftponly
         ForceCommand internal-sftp

Granted, this is SFTP and not SCP, but it reaches the same goal, more securely than with a restricted shell. Additionally, you can chroot the user if you want to.

share|improve this answer
2  
add the chrootDirectory %h and AllowTcpForwarding no after the match section to force the sftponly users to chroot to their home. please note that the match should (must!) be the last section on the ssh config and options after that are options just for the matched users –  higuita May 28 '13 at 15:44
1  
ForceCommand internal-sftp -u 0077 -d /uploaddir can farther harden it, by forcing a umask on an upload directory. In conjunction with 'ChrootDirectory` it creates a very controlled, isolated upload environment. Bonus note: the default dir and the umask must be set in the ForceCommand, not in the Subsystem directive, if you want them to work. –  Marcin Jun 6 at 12:58
add comment

I'm way late to this but you could use ssh keys and specify the exact command allowed in their ~/.ssh/authorized_keys file e.g.

no-port-forwarding,no-pty,command="scp source target" ssh-dss ...

You may need to use ps to on the target to set the right command settings.

PS: If you run a test scp command with "-v" you can see something like this

debug1: Sending command: scp -v -t myfile.txt

You will note that "-t" is an undocumented scp option, used by the program on the far end. This gives you the idea of what you need to put into authorized_keys.

EDIT: You can find more information (with several links) in this StackOverflow question.

Here is a working example of this, for a user named backup_user on the server side.

~backup_user/.ssh/authorized_keys content on server side (with some more security restrictions):

no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="scp -v -r -d -t ~/CONTENT" ssh-rsa AAAAMYRSAKEY...

Create a link in ~backup_user/ that links to the directory where the content should be accessible.

$ ln -s /path/to/directory/with/accessible/content ~backup_user/CONTENT

Now, from client side, the following command should work :

scp -v  -r  -P 2222 -i .ssh/id_rsa_key_file path/to/data backup_user@SERVER:~/CONTENT

What this command do:

  • It displays verbose information (optionnal: you can remove the -v from both command and authorized_keys file)
  • It recursively copies the content of the path/to/data. (optionnal: you can remove -r from both command and authorized_keys file if you do not want to make a recursive copy)
  • It uses port 2222 to connect to the server (optionnal: you can remove -P 2222 from the command)
  • It uses and identity file to automate the connection (optionnal: you can remove -i .ssh/id_rsa_key_file
  • The content of path/to/data will be copied into /path/to/directory/with/accessible/content/

To make a copy of a file (or several) from the server to the client, you should create a shell script that handles this as described here

share|improve this answer
add comment

I use MySecureShell to do this. You can configure other restrictions too.

http://mysecureshell.sourceforge.net/

Limits connections to SFTP/SCP only. No shell access.

share|improve this answer
add comment

I'd recommend using scponly.

It is a restricted shell that allows users to do just what it sounds like, SCP files to the server, but not actually log in. Information and source code downloads for the software are available here and the pre-compiled RPM packages are available via the EPEL YUM Repositories.

Once installed, you will need to configure each user account, which you wish to restrict access to, to use the newly installed restricted shell. You can do this manually via /etc/passwd or use the following command: usermod -s /usr/bin/scponly USERNAME

share|improve this answer
    
I second this. scponly is DESIGNED for exactly this purpose. –  UtahJarhead Sep 25 '13 at 12:16
add comment

We use a psudo shell called scponly on our secure ftp servers for users we only want to be able to scp files but not log in.

share|improve this answer
add comment

Its not the most graceful solution, but you could throw something like this into the users .bashrc

if [ "$TERM"  != "dumb" ]; then
  exit
fi

I've found that SCP users get a TERM of 'dumb', and others will typically get vt100.

I imagine the user could probably scp over a new .bashrc, which makes this not the best solution, but for a quick and dirty solution, this will work

share|improve this answer
add comment

I've found a nice way is to use the command="..." feature of the authorized_keys file. (Suggested to me by this page)

The command you'd run would be one that tests for arguments that start with scp (and rsync).

Here's the authorized_keys file:

# authorized_keys
command="/usr/local/bin/remote-cmd.sh" ssh-rsa.....== user@pewpew

Here's the contents of remote-cmd.sh:

#!/bin/bash
# /usr/local/bin/remote-cmd.sh
case $SSH_ORIGINAL_COMMAND in
 'scp'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 'rsync'*)
    $SSH_ORIGINAL_COMMAND
    ;;
 *)
    echo "Access Denied"
    ;;
esac

I guess you'd probably still need to protect the user's authorized_keys file, but my purpose was to have a password-less key that I could use for backups, without having to create a whole new user, and have the key not give a shell (ok, easily)

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.