*References*: to below 'authorized_keys base' for a more generally practical solution.
As a third authentication method, ssh supports RSA based authentication. The scheme is based on public-key cryptography.
The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key.
You can generate a public key (sort of like a Kerberos ticket) that will let you login to UNIX accounts that without typing your SSH password each time. When you first login to your local workstation, run "ssh-agent" and give it your passphrase. Then ssh will not prompt for the password; the target account must have your "identity.pub" key in ~/.ssh/authorized_keys.
The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in.
When the user logs in, the ssh program tells the server which key pair it would like to use for authen- tication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key. The challenge can only be decrypted using the proper private key. The user's client then decrypts the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server.
http://www.csua.berkeley.edu/ssh-howto.html
The security of your passphrase is of the utmost importance, because in order for ssh-agent to be of much use, your passphrase must serve to authenticate you to any machine you wish to use. This basically means that your SSH passphrase is a password that works on all the accounts of all the machines you use. Obviously, therefore, if someone figures out your SSH passphrase, they have access to all the machines you use; this is a worst-case scenario which is to be avoided. Therefore, you should take care never to type your SSH passphrase over an unencrypted network stream. Whenever you type your SSH passphrase, you NEED TO THINK about whether ANY ONE of the network connections over which you are sending your passphrase is unencrypted or otherwise "sniffable" — i.e., are you "secure to console"? If you do have insecure connections, don't enter your passphrase. Just hit return, and you can enter your UNIX password instead, or you can hit return again, log out of the insecure network connection, and try again from a secure host.
That said, here are some guidelines for picking passphrases:
- Should be between 25 and 80 characters
- Should not be English text (or the like)
- Should not be the name of any entity, person, place, …
- Should not be anything anyone could guess from hearing you talk
After you enter your passphrase, your SSH secret key will be encrypted with your passphrase, and then saved in your ~/.ssh/identity file.
ssh-keygen
— Ssh implements the RSA authentication protocol automatically. The user reates his/her RSA key pair by running ssh-keygen(1). This stores in the user's home directory:
the private key in .ssh/identity, and the public key in .ssh/identity.pub
The "identity" file should not be readable by anyone but you.
cd ~/.ssh cat identity.pub >> authorized_keys # for ssh login locally
cat identity.pub >> ~tong.iit/.ssh/authorized_keys # to log onto iitrc
— The user should then append the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine
— the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long.
— After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication.
sunshine: Trying rhosts or /etc/hosts.equiv with RSA host authentication. sunshine: Remote: Rhosts authentication refused for tong: bad ownership or modes for home directory. sunshine: Server refused our rhosts authentication or host key. sunshine: No agent. sunshine: Trying RSA authentication with key 'tong@sunshine' sunshine: Remote: Bad file modes for /export/home/tong sunshine: Server refused our key. sunshine: Doing password authentication. tong@iitrc's password:
![[Tip]](../../../../../asciidoc/images/icons/tip.png){kind=icon}
sunshine: Trying RSA authentication with key 'tong@sunshine' sunshine: Remote: Bad file modes for /home/tong/.ssh sunshine: Server refused our key. sunshine: Doing password authentication. tong@sunshine's password:
tong@sunshine:~/.ssh$ dir total 8 -rwx------ 1 tong tong 1006 Sep 27 21:01 authorized_keys* -rw------- 1 tong tong 528 Jun 6 21:23 identity -rw-rw---- 1 tong tong 333 Sep 27 21:03 identity.pub -rw-rw---- 1 tong tong 1970 May 27 12:58 known_hosts -rw-rw---- 1 tong tong 984 May 6 21:40 known_hosts.000516 -r-------- 1 tong tong 512 Jun 7 17:44 random_seed
— no problem to login from iitrc to sunshine without password. the group mod for identity.pub & known_hosts is not important
tong@sunshine:~/.ssh$ chmod 600 *
— still no problem to login from iitrc to sunshine without password. authorized_keys doesn't need the execution right!
The second (and primary) authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. It means that if the login would be permitted by .rhosts, .shosts, /etc/hosts.equiv, or /etc/shosts.equiv, and additionally it can verify the client's host key (see $HOME/.ssh/known_hosts and /etc/ssh_known_hosts in the FILES section), only then login is permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing. [Note to the administrator: /etc/hosts.equiv, .rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.]
