SSH Usage (OpenSSH)

From Elvanör's Technical Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This article deals with SSH authentication and usage. SSH allows you to do many things, including sending commands to a remote server.

SSH

Server Configuration

  • To prevent users from connecting with a simple password (and force the use of key authentication), set PasswordAuthentication to no in the /etc/ssh/sshd_config file. Be careful that UsePAM must also be set to "no". This has the side effect of preventing the resource limits set in /etc/security/limits.conf to be enabled when you login via SSH into a remote server.
  • You can always override a setting for a particular user by using the Match keyword. Example:
Match User swarm
PasswordAuthentication yes

Public Key Authentication

  • Public key authentication allows you to log in via SSH, without supplying a password. The server will use your public key to send you a challenge, that you will decrypt on the client side with your private key. To get public key authentication working, follow the following steps:
    • Generate a RSA public/private key pair on the client with ssh-keygen.
    • Transfer the public key on the server, and append it to the file ~/.ssh/authorized_keys. Note that this is dependent on the user you want to log as; if you want to use your key to log in as several users, you must add it to the authorized_keys file of each user.
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
cat ../id_dsa.pub >> authorized_keys
  • Make sure that the server configuration allows public key authentication.
  • Public key authentication requires strict permissions on several files and directories: $HOME, $HOME/.ssh/ and $HOME/.ssh/authorized_keys. Else it simply won't work. On $HOME, only the user should be able to write. On the $HOME/.ssh/ and $HOME/.ssh/authorized_keys, even read access should be restricted to the user.
  • Beware of the format of the id_rsa.pub file. If you make a mistake, for example add a new line, parsing will fail and will confuse OpenSSH.
  • Also do not change anything on the private file (id_rsa), even to add comments. This can confuse OpenSSH who might think the key is encrypted with a password (when this is not the case).

Known Hosts

  • You can use the -o 'StrictHostKeyChecking=no' option if you want ssh to accept the key without asking.

Multiple keys

  • Sometimes it is useful for a particular user to have several different keys. For example, if you access a Subversion repository via the standard SSH method, a command will be invoked when you login on the server. This prevents "normal" usage of ssh. In this case, create another key and modify your .ssh/config file:
Host svn.shoopz.com
HostName svn.shoopz.com
IdentityFile /home/elvanor/.ssh/id_dsa_svn
User elvanor
IdentitiesOnly yes
  • This will tell SSH to always use the key id_dsa_svn when connecting to svn.shoopz.com. Note the IdentitiesOnly line is extremely important; it tells ssh to not ask keychain for authentified keys (or something like that, I don't know exactly the details, but if you use Gentoo's keychain package, include this line).

Executing commands, sourcing scripts

  • Note that ssh will normally run a command on the remote server. If you don't specify a command, the default behavior is to start a shell.
  • If you have a ~/.ssh/rc file on the remote server, the commands containing in that file will be executed. Note however that they are executed before ssh spawns a shell (or the command you specified), so you cannot use that for specifying environment settings like the umask, the group etc. If you need to do that, you have to run a wrapper script.

Particular Setups

Running SSH as an user with no HOME

  • This is possible; you just need to have the hosts you wish to connect to in the global known_hosts file (in /etc/ssh). Any other user specific configuration (~/.ssh/config file) should be done in the global configuration file.
  • Note that you cannot specify a different base directory for the user when you launch ssh.

Running SSH with ForwardAgent

  • If ForwardAgent is set to yes (in /etc/ssh/ssh_config or in a user configuration file), then the keys of the host (generally local machine) can be used by an ssh process launched on a remote machine. Be aware of that as it can be very confusing!

Troubleshooting

  • When something really does not work, remember that you can check the logs on the server side to (on Gentoo they go to the system logging daemon). This can be sometimes very useful.
  • A locked account cannot accept SSH logins; to unlock, set a password on the account (via passwd).

Related programs

Keychain

  • After you emerged keychain, it is important to add the following lines to ~/.bash_profile:
keychain ~/.ssh/id_dsa
source ~/.keychain/$HOSTNAME-sh

scp

  • You can copy multiple files in one single invocation (and a single password prompt) via the following trick:
scp user@example.com:"/srv/path/{directory1/.,directory2/}" ./

The "" cause the file glob to be evaluated on the server.