Locked myself out of SSH on an Amazon EC2 box after fiddling with ForceCommand internal-sftp in /etc/ssh/sshd_config in order to allow root log-in via SFTP.

SFTP still works fine, but PuTTY dies instantly, e.g:


The odd thing here is that SFTP still works fine and permits me to log-in as root currently (because of the changes I made) - so I've got a WinSCP window open and I can trawl through whatever I like and edit stuff.

When I try to connect from another Linux box using:

ssh -i keyfile.pem ec2-user@hostname.com.au -p [portnumber]

I get the following response:

This service allows sftp connections only.
Connection to [hostname] closed.

I've successfully removed ForceCommand internal-sftp from /etc/ssh/sshd_config but I'm having trouble running service ssh restart remotely. When I do it from sftp with the ! prefix, it says it's worked - but I can tell that it hasn't because the listening port is not changing.

  • Why would you need to obviously obfuscate your actual keys in authorized_keys? They should be your public keys not your private keys. – Anthon Jul 11 '14 at 6:55
  • from the evidence you give it is not a key problem. From your evidence in your update, it looks like you have changed the configuration to allow sftp only, not shell login. – ctrl-alt-delor Jul 11 '14 at 8:05
  • @Emmanuel the evidence does not suggest that it is an authentication problem. – ctrl-alt-delor Jul 11 '14 at 8:19
  • ForceCommand internal-sftp is not needed for sftp to work, but it will stop shell login. Have you restarted sshd after fixing sshd_config? – ctrl-alt-delor Jul 11 '14 at 8:26
  • authorised_keys is fine: you have no configuration fields, and if sftp works then the key is ok. – ctrl-alt-delor Jul 11 '14 at 8:28

Removed ForceCommand internal-sftp from /etc/ssh/sshd_config and rebooted the server (to refresh the configuration file) and I'm back in.

  • This worked fine for me too.. But I got one more error that is throwing me out of PUTTY.. '/bin/bash: No such file or directory', What could be causing this issue? any idea? – yellowandred Aug 24 '18 at 10:55

When I do it from sftp with the ! prefix, it says it's worked

It has! But ! executes the command on the client, not on the server. So watch out for what you may inadvertently have changed on the client.

The SFTP protocol deliberately doesn't allow the client to specify commands to run on the server. It's only a file transfer protocol.

You may however indirectly trigger commands on the server by writing them to a file that will be executed. For example, you can drop an at job in /var/spool/cron/atjobs (if you know what to write in the job file and in the .SEQ file — the at spool format isn't completely trivial). You can edit /etc/crontab or some other crontab. Usually SFTP-only users are confined to their home directory, but with root access to the whole filesystem, SFTP without full SSH access doesn't actually provide any security, just inconvenience.


  1. Use sftp to download /etc/ssh/sshd_config and /etc/crontab.
  2. Edit the downloaded files to remove the ForceCommand line and add a cron job that runs service ssh restart (or /etc/init.d/ssh restart or whatever your init system wants) as root.
  3. Use sftp to upload the modified files.
  4. Wait for the cron job to trigger.
  5. Use ssh to log in and edit out the temporary cron job.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.