Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

How do I set up SSH so I don't have to type my password when connecting to a host?

share|improve this question
    
One might argue if using such keys does not require a password. To avoid that anyone who gets hold of your private key can actually abuse it, one can protect the key by a password of itself. Of course, one can leave that password blank, but there's many cases where that wouldn't be recommended. –  Arjan Jul 18 '09 at 17:06
add comment

10 Answers

up vote 107 down vote accepted

Generate a SSH key (if you don't have one)

If you happen to use GNOME, the seahorse application ("Passwords and Encryption Keys") can do it for you: File -> New -> Secure Shell Key.

If you prefer terminal, run ssh-keygen -t <type> to generate a keypair. Valid keypair types are:

  • rsa: the default
  • dsa: more-or-less equivalent, except restricted to 1024 bit keys
  • ecdsa: same security with smaller keys, but very new and relatively rare in SSH software

The program will ask you for a passphrase and a location where to save the new key. Using the suggested default path is recommended because all other tools will look for it there.

Upload the public key to the remote server

Again, seahorse can often do that for you - in My Personal Keys, right-click on your SSH key and choose Configure key for secure shell.

Or, ssh-copy-id -i ~/.ssh/id_rsa.pub remote-user@remote-host in the terminal.

Or, completely manually step-by-step:

  1. Create a directory (if it doesn't exist already) named .ssh in the home directory of the remote user on the remote host.
  2. In that directory, create a file named authorized_keys (if it doesn't exist already).
  3. In case your remote umask is more liberal than usual, make the file not group-writable: chmod go-w ~/.ssh ~/.ssh/authorized_keys.
  4. Finally, somehow copy (append) the contents of your local public key (~/.ssh/id_rsa.pub) into the remote ~/.ssh/authorized_keys file.

Load the key into the ssh agent

If you load your private key into a ssh agent, it will hold the decrypted key in memory. We want this to avoid re-entering the password whenever we shell into a server.

First, the agent must be started or the path of a launched communication socket be loaded into a variable. Running ssh-agent on a terminal will generate commands for assigning and setting the agent variables. These commands can be saved in a file for use in a different terminal. Alternatively, one could run these commands and forget about re-using the same agent in another terminal. e.g: eval $(ssh-agent).

Loading the key is a simple matter of executing ssh-add and giving it the pass phrase.

If you are using GNOME, gnome-keyring-daemon usually provides the same SSH agent functionality as ssh-agent, so you should not need to start anything. GNOME will automatically load and unlock the key on login, too.

Shell into the remote server without a password

If everything was done correctly, using ssh user@server will not prompt you for a password. If something is wrong with the agent and not the key, you will be asked to type in the pass phrase for the key, and not the password for the user account.

Anything that uses ssh for communication will work without entering the user account password when the correct key is loaded in the agent. Programs such as scp, sftp and rsync make use of this.


Notes:

  • You only need a SSHv2 key, as SSHv1 is very insecure and now unused.
  • You also only need one type of key - either RSA or DSA is enough. (ECDSA is rather recent and thus not supported everywhere).
  • All these steps are the same for both RSA and DSA keys. If you use DSA, use id_dsa instead of id_rsa, and ECDSA will have id_ecdsa.
  • OpenSSH servers older than 3.0 used authorized_keys2 - but it is really unlikely you'll find anything older than 5.0 in use.
  • These instructions only apply for OpenSSH version 3.0 and newer. lsh, ssh.com, and other (Unix and not) SSH servers are not included in this tutorial.

Examples:

  • Copying the public key to a remote host:

    ssh-copy-id -i ~/.ssh/id_rsa.pub myaccount@remotehost       # this
    
    cat ~/.ssh/id_rsa.pub | ssh myaccount@remotehost \
          'mkdir -p ~/.ssh ; cat >> ~/.ssh/authorized_keys'     # or this
    
  • Saving agent variables for re-use (elaborate example)
    ssh-agent > ~/.ssh/cross-terminal-agent
    . ~/.ssh/cross-terminal-agent
    
share|improve this answer
3  
ah, you have to say "ssh-add {path-to-private-key-file}" and then it will ask you for your passphrase. Please make this more explicit in your post. You should also add "Fourth, run ssh". Part of the problem with the documentation with this stuff is that it glosses over seemingly obvious steps that are NOT obvious for someone new to the process who has no idea what's going on and how these programs work together. –  Jason S Jul 18 '09 at 18:47
1  
Jason: ssh-add -l is to check if an agent is running. ssh-add without arguments will add the key from the default location (which is ~/.ssh/id_rsa). Anyway, updated. –  grawity Jul 18 '09 at 19:05
4  
there's a command ssh-copy-id that copies the public key to the target host and sets permissions automatically. –  hasenj Jul 25 '09 at 4:54
1  
Great answer! It is missing a bit about the file permissions of the key files - I just had a problem relating to that today. The private key file should only be accessible by me, and the public key file should only be writable by me. –  ripper234 Oct 28 '10 at 8:42
1  
Fantastic answer man grete +! –  Roshan Feb 15 '12 at 5:57
show 2 more comments

Putty has a -pw option that let's you create a shortcut on desktop like this:

"C:\Program Files\PuTTY\putty.exe" -ssh user@192.168.2.2 -pw your_password
share|improve this answer
add comment

I wrote this very very short tutorial after getting REALLY REALLY frustrated with REALLY REALLY long tutorials cos really it's so simple :)

test -f ~/.ssh/id_rsa.pub || ssh-keygen -t rsa #press enter twice if given prompts, then "ssh-add"

scp ~/.ssh/id_rsa.pub destID@destMachine:/tmp/ #type password

ssh destID@destMachine #type password

cat /tmp/id_rsa.pub >> ~/.ssh/authorized_keys

rm /tmp/id_rsa.pub
share|improve this answer
add comment

If you want to do it all in the terminal in Linux:

On the host

cd ~/.ssh/

ssh-keygen -t {rsa|dsa} -b {1024|2048|4096} -C "some comment text if you want" -f id_ArbitraryName

The items in the {} are options, use rsa or dsa and choose the bit size (bigger is more secure)

Then you need to add the permissions to the authorized_keys and authorized_keys2 files.

cat id_ArbitraryName.pub >> authorized_keys

cat id_AribtraryName.pub >> authorized_keys2

Then download the id_AribtraryName file to the box you want to ssh from. If the connecting box is unix based, a config file may be necessary (in putty, someone above covered that).

On the Connecting Box

In your config file - vim ~/.ssh/config

Host example.host.com # or your computer name

User username

IdentityFile ~/.ssh/id_ArbitraryName

The config file needs permissions of 600. The SSh folder needs 700.

Hope that helps if you run into the config issue that is omitted a lot.

share|improve this answer
add comment

It's possible to do this in PuTTY on Windows as well.

Once you have the public/private key pair all set up (as other answers here show) run PuttyGen. In there, load the existing private key that you've already set up, and then save it as a PuTTY private key (ppk).

Then in PuTTY, just click on the saved session you want to auto-login to and click Load. From here go into Connection -> Data in the left pane, and in "Auto-login username" type in the username for that remote server:

PuTTY username entry

After that go into Connection -> SSH -> Auth, and browse for the ppk you made in PuttyGen:

PuTTY private key entry

Then go back to the session page and save the session you loaded earlier.

share|improve this answer
    
The first image link, "PuTTY username entry", seems to be broken. –  Peter Mortensen Aug 20 '09 at 22:24
1  
PuTTY includes its own version of ssh-agent; it's called Pageant. It runs in the system tray and holds your key for you. You do not need to ever run ssh-agent, just check "Allow agent forwarding" in PuTTY's options under the Auth section, and Pageant's connection will be forwarded to the remote end to make your key agent available to it. –  Kevin Panko Aug 20 '09 at 22:48
add comment

Apart from all already been told on how to set ssh keys, I recommend Keychain as a ssh-agent console frontend which allows you to handle one only per system process instead of per login.

I know there are already GNOME and KDE tools that do the same but if you are the console junkie type this is great (and can be used on most Unix systems).

To use it, simply append the following to your ~/.bashrc (similar for other shells):

if type keychain >/dev/null 2>/dev/null; then
  keychain --nogui -q <all your SSH/PGP keys>
  [ -f ~/.keychain/${HOSTNAME}-sh ] && . ~/.keychain/${HOSTNAME}-sh
  [ -f ~/.keychain/${HOSTNAME}-sh-gpg ] && . ~/.keychain/${HOSTNAME}-sh-gpg
fi
share|improve this answer
add comment

You didn't specify what Unix you're on, what Unix you're connecting to, what shell you're using, what SSH variant you're using, etc. So some of this might need to be adjusted slightly; this is based on reasonably recent versions of OpenSSH, which is used on a lot of unix variants.

This is all from your local desktop system.

ssh-keygen

Make sure to use the default for the keyname. I suggest that you do set a passphrase on that key, otherwise it's a security problem. "-t rsa" wouldn't be a bad idea, but probably isn't needed.

ssh-copy-id username@server

That will ask you for the password you'd use to log in, and sets up the authorized_keys stuff for you. (no need to do it by hand)

Then, this:

`ssh-agent`

or maybe this:

exec ssh-agent sh

or:

exec ssh-agent bash

That will start up an SSH agent that can hold your key. On many modern Unix variants, if you're logged in graphically, this will already have taken place. The first variant (with the backticks) puts an ssh-agent into the background and sets up the environment variables to talk to it. The second two have the agent run a shell for you, so that when you exit the shell, the agent exits.

Many modern Unix variants will already have an agent running for you, especially if you logged in graphically. You might try "ps aux | grep ssh-agent" or "ps -ef | grep ssh-agent"; if something is already running, use that.

Then, finally:

ssh-add

It will ask for a passphrase; give it the one you gave ssh-keygen. There's also ways to make it ask graphically. And you can put the ssh-agent and ssh-add stuff into your login scripts (setup is different depending on shell you use) to automate this, but some Unix variants (current Ubuntu Linux, for instance) do most of that automatically, so that all you really need to do is create a key and use ssh-copy-id to set it up on the remote host.

Now, "ssh username@server" should work without asking for any authentication. Behind the scenes, it's using a key that the ssh-agent is holding, and asking the agent to do the magic signing tricks for it.

share|improve this answer
add comment

From a very similar question on ServerFault, I'd recommend using ssh-copy-id, which does all the steps involved with setting up authentication keys for you:

ssh-copy-id is a script that uses ssh to log into a remote machine (presumably using a login password, so password authentication should be enabled, unless you've done some clever use of multiple identities)

It also changes the permissions of the remote user's home, ~/.ssh, and ~/.ssh/authorized_keys to remove group writability (which would otherwise prevent you from logging in, if the remote sshd has StrictModes set in its configuration).

If the -i option is given then the identity file (defaults to ~/.ssh/identity.pub) is used, regardless of whether there are any keys in your ssh-agent.

All you need to do is simply this:

ssh-copy-id user@host

Type in your password once, and you're good to go!

share|improve this answer
add comment
  1. On the connecting host, run ssh-keygen. (If it tells you you have to specify a type, do ssh-keygen -t rsa.) When it asks you for a file location, take the default. When it asks you for a passphrase, hit enter for no passphrase.
  2. cat ~/.ssh/id_rsa.pub (or whatever the default file location in ssh-keygen was, though you'd have to have a really old ssh install for it to be different); copy the output to your clipboard.
  3. Log in normally to the destination host as the account you want to connect to. Edit the file ~/.ssh/authorized_keys (if ~/.ssh doesn't exist, slogin to someplace; this is the simple, easy way to get it created with the right permissions). Paste your clipboard (containing the id_rsa.pub from the other host) into this file.
share|improve this answer
3  
-1 for suggesting to add no passphrase. Without a passphrase, anyone reading the file can now pose as the legitimate user. –  bortzmeyer Jul 18 '09 at 17:30
2  
First, he asked to not have to type his password; I didn't really think that having to type a passphrase instead of his password would be an improvement. Second, you're wrong; that's why there's a public key and a private key, so the public key can be out in the world. –  chaos Jul 18 '09 at 17:34
    
The password in question is typed during key generation, not every time you connect. Correct? –  Richard Hoskins Jul 18 '09 at 19:42
    
No. Keys generated with a passphrase require the passphrase to be entered every time the key is used. –  chaos Jul 18 '09 at 20:58
2  
Wrong. With ssh-agent (see the accepted answer), you type the password only once per session. –  bortzmeyer Jul 18 '09 at 21:29
add comment

http://linuxproblem.org/art_9.html

Your aim

You want to use Linux and OpenSSH to automize your tasks. Therefore you need an automatic login from host A / user a to Host B / user b. You don't want to enter any passwords, because you want to call ssh from a within a shell script.

share|improve this answer
    
Thanks to whoever for the downvote (even though I gave the same source as the top vote getter at almost the exact same time). :) –  TheTXI Jul 18 '09 at 17:35
1  
The downvote wasn't mine, but I wouldn't mind people deleting their answer if they noticed someone else posted an almost similar reply a few moments earlier. –  Arjan Jul 18 '09 at 18:31
2  
Arjan: For the most part I agree with you, but when the posts are only separated by several seconds I don't necessarily think it is fair to punish the person in 2nd place. I'm not saying you have to reward them by upvoting, but downvoting gives the impression that the answer is wrong, instead of not in time –  TheTXI Jul 18 '09 at 19:05
add comment

protected by Community May 31 at 18:46

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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