Any clever way to put a password in an SSH key?

Solution 1:

No, I don't think you can do that. But why not creating a key? Create a key with ssh-keygen (without password) and copy the public part to your remote host and add it to ~/.ssh/authorized_keys.

Keep in mind that anyone getting your private key will be able to any host where you added the public key to ~/.ssh/authorized_keys .

So always keep your private key private.

As Iain commented below, more secure would be to create the key with a password but cache it using ssh-agent. Type

ssh-add your_key_file

and you will be asked for your password. It will then be cached and as long you don't logout it will stay there to be used by ssh for logins or remote command execution or by scp.

Solution 2:

Here's a relevant article about using SSH between hosts without using passwords.

Solution 3:

There are 6 main ways of accessing a server using ssh that provide some level of security:

1. using a user/password combination (Keyboard-Interactive)
2. using an ssh identity (either protected with a passphrase or not)
3. using Host-based authentication
4. using ssh certificates
5. Kerberos
6. PAM

The following might be of interest:

Identity files

To generate an ssh identify file pair use the ssh-key-gen program to generate a private (commonly ~/.ssh/id_rsa) and public (commonly ~/.ssh/id_rsa.pub) key pair. Put the public key in a 0600 mode file called ~/.ssh/authorized_keys in the login user's home. If you did not use a passphrase for your private key, you should now be able to login without using a password. However it is more sensible to protect your private key with a passphrase. One can avoid having to retype this phrase at every connection by running an ssh-agent process and loading the key and required passphrase into this. Many people spawn an ssh-agent process when starting their X session.

You can do something along the following lines if you need an ssh-agent:

   eval `ssh-agent -s`
   ssh-add [optional ssh private file if not ~/.ssh/id_rsa]
   <enter passphrase>

The file authorized_keys can contain many different keys. These can also be given special access controls through the use of controlling phrases at the beginning of each key's line in the file. For example from="192.168.1.* at the beginning of a key's record will limit the key for use by hosts connecting from 192.168.1.x addresses.

Host-based authentication

Host-based authenticated allows access using the remote hostname and username associated with it. This uses the client host's ssh key to permit access, together with the client host's verification of the user accessing the remote host. This is a weak form of security and probably should not be used at all, or if it is in use should only be used on a LAN.

Certificates

Certificates offer a lot of interesting options that, while similar to the arrangement of identity keys and authorized_keys, reverses the arrangement so that controls that normally lie in the authorized_keys file are embedded in the certificate. Want to give somebody the chance to run date on your server for the next two days only as user bob from network x? Certificates seem to be a really good way of doing this.

From man ssh-keygen:

ssh-keygen supports signing of keys to produce certificates that may be used for user or host authentication. Certificates consist of a public key, some identity information, zero or more principal (user or host) names and an optional set of constraints that are signed by a Certification Authority (CA) key. Clients or servers may then trust only the CA key and verify its signature on a certificate rather than trusting many user/host keys. Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8).

Solution 4:

Passwordless authentication is a main use case for Public key authentication (e.g. id_rsa). It would be bad security practice to place your password into a plain text configuration file (such as you .ssh/config). Instead, you should generate a private and public key as @rems mentions here and @joe mentions here. Be certain to provide an empty passphrase to the private key when you create it with ssh-keygen.