SSH Usage (OpenSSH): Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
Line 49: | Line 49: | ||
* 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. | * 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. | * 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 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. | |||
= Troubleshooting = | = Troubleshooting = |
Revision as of 18:45, 15 March 2010
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".
- 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.
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 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.
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.