openssh unix dev - Apr 2001 - Restrict account to only use sftp not working

Hi all,

I'm setting up a system where users will only be able to use
"sftp" but not
"ssh" to connect to the server
(http://www.snailbook.com/faq/restricted-scp.auto.html). Here's the setup...

Server: OpenSSH 2.5.2p2-1 on RH Linux
Client: Commercial SSH 2.4 on Solaris

The vendor on the client system creates a key pair and sends it to me.  I
then add the vendor's public key to the authorized_keys2 file on the account
on the server that the vendor will be using:
__________________________________________________________________________

from="server.vendor.com",command="/usr/libexec/openssh/sftp-server",no-port-
forwarding,no-X11-forwarding,no-agent-forwarding ssh-dss <rest of key...>
__________________________________________________________________________


But when the vendor logged in using the ssh2 client, here's what happened:

___________________________________________________________________________

{vendor on telluride}/export/home/vendor% ssh -d2 vendor at ftserver
debug: connecting to ftserver...
debug: entering event loop
debug: ssh_client_wrap: creating transport protocol
debug:
SshAuthMethodClient/sshauthmethodc.c:105/ssh_client_authentication_initializ
e: Added "publickey" to usable meth
debug:
SshAuthMethodClient/sshauthmethodc.c:105/ssh_client_authentication_initializ
e: Added "password" to usable metho
debug: Ssh2Client/sshclient.c:1104/ssh_client_wrap: creating userauth
protocol
debug: Ssh2Common/sshcommon.c:487/ssh_common_wrap: local ip = ...., local
port = 32912
debug: Ssh2Common/sshcommon.c:489/ssh_common_wrap: remote ip = ...., remote
port = 22
debug: SshConnection/sshconn.c:1853/ssh_conn_wrap: Wrapping...
debug: Ssh2Transport/trcommon.c:593/ssh_tr_input_version: Remote version:
SSH-2.0-OpenSSH_2.5.2p2
debug: Ssh2Transport/trcommon.c:1068/ssh_tr_negotiate: c_to_s: cipher
3des-cbc, mac hmac-sha1, compression none
debug: Ssh2Transport/trcommon.c:1071/ssh_tr_negotiate: s_to_c: cipher
3des-cbc, mac hmac-sha1, compression none
debug: Ssh2Client/sshclient.c:399/keycheck_key_match: Host key found from
database.
debug: Ssh2Common/sshcommon.c:297/ssh_common_special: Received
SSH_CROSS_STARTUP packet from connection protocol.
debug: Ssh2Common/sshcommon.c:347/ssh_common_special: Received
SSH_CROSS_ALGORITHMS packet from connection protocol.
debug:
Ssh2AuthPubKeyClient/authc-pubkey.c:777/ssh_client_auth_pubkey_agent_list_co
mplete: adding keyfile "/export/hom
Forced command: /usr/libexec/openssh/sftp-server
debug:
Ssh2AuthPubKeyClient/authc-pubkey.c:330/ssh_client_auth_pubkey_send_signatur
e: Constructing and sending signatu
debug:
Ssh2AuthPubKeyClient/authc-pubkey.c:423/ssh_client_auth_pubkey_send_signatur
e: ssh_client_auth_pubkey_send_sign
Port forwarding disabled.
X11 forwarding disabled.
Agent forwarding disabled.
Forced command: /usr/libexec/openssh/sftp-server
Port forwarding disabled.
X11 forwarding disabled.
Agent forwarding disabled.
debug: Ssh2Common/sshcommon.c:263/ssh_common_special: Received
SSH_CROSS_AUTHENTICATED packet from connection protocol
Authentication successful.
debug: Ssh2Common/sshcommon.c:686/ssh_common_new_channel: num_channels now 1
debug: DISPLAY not set; X11 forwarding disabled.
...
___________________________________________________________________________


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.  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?

> 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