Dario Lesca wrote:
Hi, someone know howto disable the execution of any command via ssh and disable the scp/sftp service?
OK; ssh user@host NO: ssh user@host cat /etc/passwd
NO: scp user@host:/etc/passwd /tmp
NO: sftp user@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
