There are 6 main ways of accessing a server using ssh that provide some level of security:
- using a user/password combination (Keyboard-Interactive)
- using an ssh identity (either protected with a passphrase or not)
- using Host-based authentication
- using ssh certificates
The following might be of interest:
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]
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 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 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.
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).