This is a typical example of a trade-off between security and convenience. Luckily there are a number of options. The most appropriate solution depends on the usage scenario and desired level of security.

**ssh-key with passphrase, no** `ssh-agent`

Now the passphrase has to be entered every time the key is used for authentication. While this is the best option from a security standpoint, it offers the worst usability. This may also lead to a weak passphrase being chosen in order to lessen the burden of entering it repeatedly.

**ssh-key with passphrase, with** `ssh-agent`

Adding the following to `~/.bash_profile` will automatically start `ssh-agent` and load the ssh-key(s) on login:

    if [ -z "$SSH_AUTH_SOCK" ] ; then
      eval `ssh-agent -s`
      ssh-add
    fi

Now the passphrase must be entered upon every login. While slightly better from a usability perspective, this has the drawback that `ssh-agent` prompts for the passphrase regrdless of if the key is to be used or not during the login session.

On desktops, ssh-agents included with the desktop environment, such as the [Gnome Keyring SSH Agent][1], can be a better approach as they typically can be made to prompt for the passphrase the first time the ssh-key is used during a login session and store the decrypted private key in memory until the end of the session.

**ssh-key with passphrase, with** `keychain`

[`keychain`][2] is a small utility which manages `ssh-agent` on your behalf and 
allows the `ssh-agent` to remain running when the login session ends. On subsequent logins, `keychain` will connect to the existing `ssh-agent` instance. In practice, this means that the passphrase must be be entered only during the first login after a reboot. On subsequent logins, the unencrypted key from the existing `ssh-agent` instance is used. This can also be useful for allowing passwordless RSA/DSA authentication in `cron` jobs without passwordless ssh-keys.

To enable `keychain`, install it and add something like the following to `~/.bash_profile`:

    eval `keychain --eval id_rsa`

From a security point of view, this approach is worse than session specific `ssh-agent` instances, but it offers a high level of convenience. To improve the security of `keychain`, some people add the `--clear` option to their `~/.bash_profile` keychain invocation. By doing this passphrases must be re-entered on login as above, but `cron` jobs will still have access to the unencrypted keys after the user logs out. The `keychain` [README][2] has more information and examples.

**ssh-key without passphrase**

From a security standpoint, this is the worst option since the private key is entirely unprotected in case it is exposed. This is, however, the only way to make sure that the passphrase need not be re-entered after a reboot.

**ssh-key with passphrase, with** `ssh-agent`, **passing passphrase to** `ssh-add` **from script**

While it might seem like a straightforward idea to pass the passphrase to `ssh-add` from a script, e.g. `echo "passphrase\n" | ssh-add`, this is not as straighforward as it seems as `ssh-add` [does not read the passphrase from `stdin`, but opens `/dev/tty` directly for reading][3].

This can be [worked around][4] with [`expect`][5], a tool for automating interactive applications. Below is an example of a script which adds a ssh-key using a passphrase stored in the script:

    #!/usr/bin/expect -f
    spawn ssh-add /home/user/.ssh/id_rsa
    expect "Enter passphrase for /home/user/.ssh/id_rsa:"
    send "passphrase\n";
    interact

Note that as the passphrase is stored in plaintext in the script, from a security perspective, this is hardly better than having a passwordless ssh-key. If this approach is to be used, it is important to make sure that the `expect` script containing the passphrase has proper permissions set to it, making it readable, writable and runnable only by the key owner.

[1]: http://wiki.gnome.org/GnomeKeyring/Ssh "Gnome Keyring SSH Agent on Gnome Wiki"
[2]: http://github.com/funtoo/keychain "keychain on GitHub"
[3]: http://superuser.com/questions/569432/why-can-i-see-password-prompts-through-redirecting-output "Why can I see password prompts through redirecting output?"
[4]: http://stackoverflow.com/questions/459182/using-expect-to-pass-a-password-to-ssh "Using expect to pass a password to ssh"
[5]: http://expect.sourceforge.net/ "The Expect Home Page"