4

My host uses passwords instead of id_rsa's to SSH in. But instead of typing the password everytime, is there a way to put the password in my .ssh/config ?

For example:

Host gravy_access
Hostname 127.0.0.1
User my_name_is_gravy
Password gravy_password

So that when I ssh gravy_access it'll instantly allow access.

Trip
  • 205
  • 4
  • 9

6 Answers6

9

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.

rems
  • 2,260
  • 13
  • 11
  • 1
    Instead of using keys without a pass phrase use ssh-agent or pagent or similar to hold them securely. Then, if the private key is stolen it cannot be used. – user9517 Feb 18 '11 at 18:09
  • So your public key is *always* the same everytime you generate it? – Trip Feb 19 '11 at 02:20
  • I don't get your question. You don't regenerate any public key. You have a private key with it's corresponding public key, and on generation you put a password. Then you add your public key to the remote host's ~/.ssh/authorized_keys file. Before starting a connection you add the key to the authentication agent, using ssh-add ~/.ssh/your_private_key, typing your password once. From then on, you don't have to type the password anymore for that key up to next logout, since it's cached by the authentication agent. – rems Feb 21 '11 at 11:59
4

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

Community
  • 1
Joe
  • 1,775
  • 15
  • 23
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).

rorycl
  • 848
  • 1
  • 6
  • 10
1

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.

Community
  • 1
Jeff Stice-Hall
  • 349
  • 2
  • 5
0

If you have no other choice (because you have no access to the server configuration and because key authentication is forbiden by some silly rule in your organisation), you can use sshpass, a small tool faking interactive password typing.

jon_d
  • 683
  • 4
  • 7
0

As others have said, create yourself a key pair and deploy the public key to the remote host. Don't however be tempted to create keys without a passphrase. Use an ssh-agent to hold the private keys securely for you. If you are using the PuTTY on windows then you can use Pageant otherwise there is ssh-agent.

Using an agent still requires you to enter a password to unlock the key but you can configure how long the key will be held before it requires unlocking again. This is much safer than a key without a passphrase.

user9517
  • 115,471
  • 20
  • 215
  • 297