5 Answers
5

One thing i 'll like to add is that it would be better to exclude foo guy from being able to login from ssh
What i mean is to connect to the server as user "superman" and afterwards using su foo to become foo user and execute any command you want

Using this way, the attacker needs both password / private key in order to be able to use capistrano. If he was the private key, he can connect to the server but cannot execute capistrano. if he has the password, he can't even connect to the server because user foo is not allowed to login.

If you're using SSH keys for authentication and someone steals them, it's the very same situation as if someone stole that user account's password; in both cases, he'd gain the privileges associated with that account.

This is why SSH access to a public server should not be allowed from outside your company network: this way, even if someone knew the root password, he just couldn't use it to connect to your web server.

I hope you are protecting that server with a firewall, or, failing that, you are at least using the web server's built-in one (IPTABLES on Linux, I'd guess) to only allow HTTP/S traffic from the outside. If you aren't... well, do it. Now.

it's not really a capistrano issue, more a ssh one. If you are allowed to log on a machine via ssh (with key or password) if an attacker find those credentials he can also do what you're allowed to do on those machine. your sysadmin have to set boundaries to what your deploy account can do (file permission, command permissions...).
There's a nice walktrough of how to secure ssh for those task here http://www.linuxjournal.com/article/8257