Re: scp, no ssh
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 bob@remotehost.com 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 bob@remotehost.com /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 bob@remotehost.com:/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 bob@remotehost.com 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
Reply to: