HowTo Disable execution of commands whit ssh and scp/sftp

[John Haxby]

Dario Lesca wrote:

>Hi, someone know howto disable the execution of any command via ssh and
>disable the scp/sftp service?
>
>OK; ssh user at host 
>NO: ssh user at host cat /etc/passwd
>NO: scp user at host:/etc/passwd /tmp
>NO: sftp user at host
>  
>
Apart from sftp (which as someone else said), the short answer is "no".

You can't realistically control all the commands like this.   SELinux 
might help, but I'm not sure and it's very hard to restrict a user's 
environment.    Take the password file -- suppose you do prevent a user 
from just looking at it with cat, less, more, vi, view, emacs, xemacs, 
joe, jed, pico, dd, etc etc but still have ls work.   "ls -l /home" will 
give you a fair slice of the password file in a different form.   Type 
"echo ~<tab><tab>" in the shell and you'll also get a list of users.    
You could remove global read access from the password file, but you'll 
be surprised how many things break if you do.   I once had the 
displeasure of maintaining a program that gave specified users access to 
a limited set of commands as root.    It had a list of proscribed 
programs to stop you getting a shell to do what you like unaudited, 
things like sh, csh, ksh, bash, tcsh and so on.   Of course, it didn't 
proscribe less, more, vi, view, emacs, xemacs, xterm, hpterm, dxterm 
etc.   I simply removed the feature in the new version of the program, 
there's not much worse than having supposed security that is so easy to 
get around you'd hardly notice it was there.

However, as someone else suggested.   There is another way.   A chrooted 
environment (like the one used for anonymous ftp) will lock a user into 
a limited environment.    The only files that the user can get at are 
the ones in that chroot'd environment and there's no way to get out, you 
can't "cd .." from /.   There are some really serious downsides to 
this.   It's really quite difficult to set up and I'm not even sure that 
ssh has the right hooks to enforce it ("ssh host ls" runs /bin/ls 
directly, it doesn't go through a chrooting shell entry in /etc/passwd 
an I don't recall anything in the sshd config that forces a chroot.    
You could patch sshd to do it, but it's a measure of the difficulty of 
getting it to work effectively that it hasn't been done.

That was a long no.   Although I don't know much about it, I think 
you're better off looking at SELinux which almost certainly solves the 
security problems that you actually want to solve even if you don't know 
what they are -- yet.

jch