On Wed, 2002-01-09 at 21:23, Joel Michael wrote: > On Thu, 2002-01-10 at 12:19, Tim Quinlan wrote: > > how about setting the user's shell to /bin/true. this allows ftp, but no > > login shell. so it may work for scp as well. > > > This is true, but you can still (probably) use ssh to execute commands, > like /bin/sh, and effectively get a shell.
The above assumption is wrong. Ssh executes commands by passing them as arguments to the user's shell. For example, if the user executes the ls command by connecting with $ ssh [EMAIL PROTECTED] ls /home/bob/ and the user's shell is set to /bin/bash, then the shell executed on remotehost.com will be equivalent to executing /bin/bash -c "ls /home/bob/" instead of the user's normal login shell. So, if you set the user's shell to /bin/true, all that will happen when your friendly hacker tries to connect with $ ssh [EMAIL PROTECTED] /bin/bash is that instead of runing a shell, the benign command /bin/true -c "/bin/bash" will run. After the "shell" that ssh tries to execute exits, ssh immediately closes the connection, so when /bin/true exits (which is immediately, of course) ssh will close the connection, not allowing the remote user any further actions. ---- This is all fine and dandy, but it doesn't answer the initial question of how to make scp work, but not allow shell logins; here goes on that one: Scp, in simplified terms, is just a wrapper for ssh, if I run $ scp [EMAIL PROTECTED]:/home/bob/file.txt /home/alice/file.txt scp will make the connection to the remote host with ssh, and request that another copy of scp be run on the remote host. The details aren't important, but it runs something like the command ssh [EMAIL PROTECTED] scp -f /home/bob/file.txt which in turn connects to remotehost.com and passes the specified command to bob's shell as /bin/bash -c "scp -f /home/bob/file.txt" Now, the trick is to replace bob's shell with a (perl?) script that takes -c argument passed and checks if scp is the intended command. If scp *isn't* the intended command, it merely exits, thus closing the remote connection and effectively denying access to other commands. If scp *is* what was requested, the script could just exec scp with the requested options in place of itself and everything should continue as normal. If you wanted to, you could even get really fancy and have the script deny access to certain directories or types of files. Of course, I don't imagine that the ssh/scp combo was intended to be used like this, so one should be careful while implementing, but other than that, the only downside I can think of is that the user on the remote system becomes useless for any purpose other than scp-ing. Hope that makes sense. Later, Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
