Passwordless logins in Unix
Notes on Passwordless Logins in Unix from SoftPanorama
Connecting via SSH, requires a user provide his identity to the remote machine using one of several methods. Â One method lets you access the remote system without entering a password at each login. Â Normally, when you log in to a system, you authenticate by entering your password for that system. Your password goes, as it is typed, to the remote system, which authenticates it against the /etc/passwd or /etc/shadow file. By contrast, SSH allow a “password-less” authentication method based on public-key cryptography.
SSH provides two solutions to allow remote logins without password:
/etc/shosts.equiv and .shosts method which is similar to the method using /etc/hosts.equiv and /.rhosts. This form of authentication it is not secure. However this weak authentication method can be combined with RSA-based host authentication where the client’s host key is checked with the known_hosts file of the remote machine. Â The solution based on the public cryptography:
First the user needs to create his key pair using ssh-keygen. Â The private key is stored in ~/.ssh or other directory, depending on the client used.Â The public key is in the file ~/.ssh/authorised_keys on the server.
Note: The access to both authorized_keys and client-based private key must be restricted. They should have permissions 600 on Unix.
Usually the user creates the pair on the server and then copies his private key to the client. After that there are two steps to ensure successful authentication.
Append his public key to the ~/.ssh/authorized_keys in his home directory on the server (remote machine).
Copy private key to the Windows machine in the directory that contains Teraterm of Putty (you can also use the user directory).
Verify and reset permissions:
chmod 755 ~
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
SSH is very strict about the permissions that you have on your remote .ssh directory and the files underneath. Most of the problems you will have with SSH are due to the writable permissions for a group or world that you have on the files and directories on the remote side.
A private/public keys pair is generated using ssh-keygen command line utility. The user will be prompted three times during the generation of the keys: once for the name of the output file and twice for the passphrase, just hit enter three times.
During a login, SSH will look for a file named authorized_keys in the user’s ~/.ssh directory. This file contains the keys of users allowed to login to this account. Essentially, it’s a challenge-response mechanism: You can authenticate against a public key on the server, so when the client connects, the server encrypts a random number with the public key. If the client possesses the private key, then it can decrypt the random number and report it back to the server. That proves to the server that the person logging in has the authorized private key.
The private key can be further protected when you encrypt it with a password. The password you type to authenticate via public key cryptography is the password for your private key.
The critical part of this authentication scheme is a pair of public and private keys. The ssh-keygen command is used to generate them. Here there are several options as there are several versions of the SSH protocol and OpenSSH 2.5 and higher can generate three different types of keys:
rsa1, for compatibility with SSH version 1 clients;
DSA, for connecting to SSH protocol version 2 clients using the Digital Signature Algorithm;
RSA, for connecting to SSH protocol version 2 clients using the standard RSA algorithm.
The security of most other public-key algorithms — ElGamal, DSA, etc. — is based on the discrete logarithm problem. The two problems are very similar, and all of the modern factoring algorithms can be used to calculate discrete logarithms in the multiplicative group of a finite field. To a rough approximation, factoring a number of a certain size and calculating the discrete logarithm of numbers the same size takes the same amount of work. This means that for a given key size, RSA, ElGamal, DSA, etc. are approximately equally secure.
You can set the type of key SSH generates with the -t option. Thus to generate your rsa1 public and private key pair, you would run ssh-keygen -t rsa1. For the three key types, the keys generated are by default stored in your .ssh directory beneath your home directory. The rsa1 keys are named identity, DSA keys are named id_dsa, and protocol version 2 RSA keys are named id_rsa. Each key has a corresponding public key has a .pub extension. You want to check the permissions on the private keys and make sure that they’re not world-readable; these are secrets not intended for sharing.
To allow authentication, you must make the public key available on the computer into which you would like to log in.
For rsa1 keys, the name of the file into which you put the public key is $HOME/.ssh/authorized_keys.
For SSH protocol version 2 keys (both RSA and DSA), the file is $HOME/.ssh/authorized_keys2. Each public key is a single line, so you can use scp to copy the public keys to the destination system and then, on the remote system, type cat id_dsa.pub >> .ssh/authorized_keys2. After that you can authenticate without sending any sort of password over the network. (The private key is decrypted on the client only.)
All that is very useful, as you can set your system to require authentication only once. You can do that with the SSH authentication agent, ssh-agent. The ssh-agent syntax is rather strange: because it must set some shell variables, you must use eval `ssh-agent`. The ssh-agent tries to determine the shell syntax necessary, but occasionally it fails and you need to pass it the -s option for Bourne shell derivatives such as ksh and zsh, or the -c option for C Shell derivatives.
You must execute the ssh-agent in your top-level shell for maximum usability. For a console or ssh-based session that means in your top login shell or, for X-based sessions, in your .Xclients or another startup script. In either case, you must kill the ssh-agent with ssh-agent -k prior to quitting, or lots of startup files will be left around.
The ssh-agent only manages keys; you have to tell it which keys to use. To do that, you can ssh-add private-key-file, where private-key-file is $HOME/.ssh/id_dsa or one of your other private keys. Once you type the passphrase for your key, ssh-agent remembers it and automatically handles the key requests from new SSH sessions. To handle all contingencies, I add all three of my keys at login time and forget about it until I’m ready to quit. I end up typing three passwords, and then I need not enter any more passwords for the rest of the day.
If you plan on connecting through one server to another server, you can connect via SSH to that first server with the -A option, which allows the server to pass any authentication requests it gets back to the initial client. (You can make that operation the default by setting ForwardAgent yes in your ssh configuration file. The per-user configuration file is $HOME/.ssh/config, and the systemwide configuration file is usually in /etc/ssh/ssh_config depending on how you installed OpenSSH.