Restrict account to only use sftp not working

Davis, Ricardo C. RCDavis at intermedia.com
Sat Apr 21 08:28:46 EST 2001


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?



More information about the openssh-unix-dev mailing list