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.

I'm running Debian stable and I'm looking to establish the following environment for users in my 'sftponly' group:

  • jailed
  • can transfer with SFTP
  • can transfer with SCP
  • cannot login interactively with SSH

From my experimentation and research, it seems that the following stanza in sshd_config gets me 90% there:

Match group sftponly
ChrootDirectory /sftp/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp

This gives me jailed SFTP and no SSH, which is good. But it also disables SCP, which is less than ideal because quite a few clients are legacy, scripted processes that use SCP rather than SFTP (the server we're replacing supported both protocols), and since those clients are not under our control and easily modified, it's likely not practical to disable SCP altogether.

It makes sense that this configuration would disable SCP, as incoming SCP connections cause sshd to spawn an `scp' process via the user's login shell, as that user. It seems that the same would normally be true of SFTP, were it not for the special 'internal-sftp' handler.

So, I suppose my question is: is there a way to achieve the same effect as 'internal-sftp' but for SCP, without resorting to the use of third-party tools like scponly and rssh? The really nice thing about 'internal-sftp' is that it doesn't require setting up a jail with support files, or dealing with potentially-exploitable third party setuid binaries (rssh, in particular, has a history of exploits).

share|improve this question
1  
Are the clients connecting using an ssh key file, or are they using passwords? If it's a keyfile, it's possible to restrict what they can do. –  Jenny D Aug 23 '12 at 14:56
    
They are connecting with passwords. –  brianjcohen Aug 23 '12 at 15:57

4 Answers 4

Here is a trick on how to perform this serverside. Set the shell of the users to, say, bash:

usermod -S /bin/bash [username]

Now create in their homedir a '.bash_profile' with the following line:

[ -n "$PS1" ] && exit

This causes non-interactive sessions (like 'scp') to continue. However, if they attempt an 'ssh' login, the 'exit' is called, and the connection is closed.

Make sure they cannot 'sftp' a new '.bash_profile' into their home directories!

chown root:root .bash_profile

Hope that helps!

share|improve this answer
    
This approach does not seem to take the requirement for the jail into account. –  brianjcohen Aug 23 '12 at 15:58
    
Yes, unfortunately you would have to create a manual chroot environment for the 'scp' side, overlapping with the chroot directory given in sshd_config, and perform the above trick for each user you want to restrict. The 'scp' does not work with the internal sftp server. –  Vince Berk Aug 23 '12 at 16:13

Do you need to do this through ssh?

IF so you can try setting their shell to:

/usr/libexec/openssh/sftp-server

And make sure you add the above into /etc/shells

If you want to decouple from using built in accounts, you can setup proftpd

I setup a secure SFTP using proftpd. compiled proftpd like so:

./configure --prefix=/usr --sysconfdir=/etc --with-modules=mod_sftp

Can use this article below, and some more on google on how to set it up:

http://tutorialgenius.blogspot.com/2012/02/linux-installing-and-configuring.html

share|improve this answer

I'm afraid there is nothing similarly easy or reliable with OpenSSH, since as you observed there is a built-in SFTP server, but no built-in SCP server.

A warning: the suggestion by Vince Berk is bad for a number of reasons:

  1. The shell's behavior with regard to startup files can be influenced by environment variables, which SSH can remotely set depending on server configuration.
  2. The user can just run ssh /bin/bash and get a shell. It won't have a tty and so will be inconvenient to use, but so what... not to mention all the other programs he can run that you presumably don't want him to.
  3. Changing the permissions of .bash_profile does little good if the user can just do "ssh host rm -f .bash_profile"; nothing was mentioned about the home directory permissions.

... and so on. This sort of approach is just way too fragile.

share|improve this answer

Take a look at rssh which is an alternative shell that allows limited access to a system.

rssh is a restricted shell for providing limited access to a host via ssh(1), allowing a user whose shell is configured to rssh to use one or more of the command(s) scp(1), sftp(1) cvs(1), rdist(1), and rsync(1), and only those commands.

You can configure which commands can be used on a per-user or system wide basis using the rssh.conf file

Alternatively you can use scponly to do what you want. It acts as a wrapper to the ssh suite and allows file transfer but not shell access.

share|improve this answer

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.