Restrict account to only use sftp not working

Richard E. Silverman slade at shore.net
Mon Apr 23 05:58:39 EST 2001


> After the "Authentication successful." message, the vendor did not get a
> system prompt.  But the vendor could get a listing and move around the
> filesystem. I would expect that the vendor would not be able to do anything.

I don't understand.  You wanted to restrict the account to using sftp.  The
client could use sftp, but not do anything else ("get a system prompt").  In
what way does this behavior not correspond to your expectations?

> Indeed, to test this I set up an account on the server and used the OpenSSH
> "ssh" client to log into the account as the vendor did.  I authenticated but
> didn't get a command prompt and when I typed any command the server
> responded with "bad command" and exited.  If I used the OpenSSH "sftp"
> client and logged in, it operated as expected.
> 
> Did I missing something in setting up the server, or was the client able to
> do something it shouldn't have?

No, and no.  I still don't understand what you think is wrong.  If you read
the snailbook.com page you mentioned, then you understand that the sftp client
works by running ssh in a subprocess to connect to the server and run the
sftp-server.  So of course, you can run the SSH client by hand and do the same
thing.  You got a connection to sftp-server.  When you typed text at it, it
exited because the text did not fit the SFTP protocol.

Note also the comments on that web page about the difficulty of securing this
if you choose not to employ a limited shell for the account.  For instance, if
sshd uses the shell to start sftp-server, and the target user can write the
account's shell startup files using sftp (~/.login, ~/.bashrc, etc.), then the
client can arrange to run arbitrary programs anyway.  sshd2 has
AllowCshrcSourcingWithSubsystems set to false by default, so that it passes -f
to the shell to suppress some startup processing, but how that's interpreted
and how effective it will be depends on the shell...

- Richard



More information about the openssh-unix-dev mailing list