Q:

Is it possible to prevent SCP while still allowing SSH access?

Using Solaris and Linux servers and OpenSSH, is it possible to prevent users from copying files using "scp" while still allowing shell access with "ssh"?
I realize that 'ssh $server "cat file" ' type file accesses are much harder to prevent, but I need to see about stopping "scp" for starters.
Failing that, is there a way to reliably log all SCP access on the server side through syslog?

A:

While you could edit your /etc/ssh/sshd_config to look something like this:
ForceCommand           /bin/sh
PermitOpen             0.0.0.0
AllowTcpForwarding     no
PermitTunnel           no
# Subsystem sftp       /usr/lib/openssh/sftp-server
PermitUserEnvironment  no

I would instead determine what the user is likely to use it for. Because if there are only a few commands that you want them to have access to, I would instead remove the ability for them to even invoke a normal ssh shell.
AllowUsers             root
PermitRootLogin        forced-commands-only

PermitUserEnvironment  no

AllowTcpForwarding     no
PermitTunnel           no

# Subsystem sftp       /usr/lib/openssh/sftp-server
Subsystem smb-reload   /usr/bin/smbcontrol smbd reload-config
Subsystem status       /opt/local/bin/status.sh

ssh root@example -s smb-reload

If you find that you really do need to be able to run a normal shell, the most you really can hope for, is to slow them down, and make it more difficult.

A:

As others have noted, you can't block scp (well, you could: rm /usr/bin/scp, but that doesn't really get you anywhere).
The best you can do is to change the users' shell to a restricted shell (rbash) and only then to run certain commands.
Remember, if they can read files, they can copy/paste them off the screen. Binary files? xxd/uuencode/mmencode all get around this.
I'd also suggest using process accounting to help you track activity.

A:

You gain nothing by stopping "scp" when you're still allowing literally infinite additional mechanisms of transferring files. Disallowing scp but allowing other mechanisms of copying files is a method of lying to auditors. Often auditors ask to be lied to. Usually I see auditors working with managers to make fake fixes, so that they can state something like "the scp file transfer command has been disabled, so that files can not be copied from the server using scp".
Now a reasonable logging mechanism would be nice. Maybe auditd finally works on Linux. Maybe Solaris finally added some mechanism or dtrace could be used safely. It's reasonable to want the OS to log every time a file is accessed. Of course there's no difference between "reading" and "copying". But this can satisfy an auditor and give significant security to the system. Your logs could be so noisy that the data is useless, or even that you're forced to keep a ridiculously short audit trail. (e.g. you can't log every read() - and one application that does something surprising can make logging every open() a disaster).

