SSH is a popular cryptographic network protocol for secure network service operation. It is frequently used in remote server login. For a system administrator or software developer, SSH is frequently used to access remote servers or development servers or testing servers etc.
To login with SSH, there are different authentication mechanisms : password, public key and interactive etc. If a remote server needs to be accessed frequently, password authentication may be too troublesome as password needs to be typed every time. In this scenario, public key authentication would be a life saver. It needs to be set up only once and thereafter the server can be logged in automatically without any password.
Public key authentication uses the asymmetric key cryptographic technique so that one side can use a public key or private key to encrypt data while the other side can use the corresponding private key or public key to decrypt the data. This is a very secure mechanism where no key needs to be transferred over the network. The public key can be distributed freely to the public as long as the private key is kept secret.
In SSH, public key authentication can be used to achieve authentication automation. The rationale behind this is that the end user will have a private and public key pair. The public key will be added to the authorized keys list on the remote server, thereafter the end user can use the private key to authenticate to the server.
The detail steps on how public key authentication can be set up are as follows:
- The end user generates the key pair. It can be generated using OpenSSH with command ssh-keygen. For example :
ssh-keygen -t rsa
The above command will prompt for some input from the user and then generate a RSA keypair in ~/.ssh/id_rsa(Private key) and ~/.ssh/id_rsa.pub(Public key). Other algorithms are supported such as DSA and ECDSA - The next thing is to upload the public key to the remote server. Assume the user wants to login as user1 to the remote server, then the public key of the user needs to be added to the /home/user1/.ssh/authorized_keys file. The command to add the public key is :
cat ~/.ssh/id_rsa.pub | ssh user1@[hostname] 'cat >> /.ssh/authorized_keys'
Confirm that the public key is added correctly after above step. - Ensure the folder ~/.ssh folder has permission 700 and ~/.ssh/authorized_keys has permission 600 on the remote server.
Try to login to the remote server automatically now with command
ssh user1@[hostname]
In some rare cases, the password prompt still shows up after above set up id done. This usually indicates there are some problems with the setup or there are policies on the remote server which prohibit the public key authentication. Debugging is needed to assist in resolving the problem.
Some possible causes for the failing public key authentication are:
- The public key is not added correctly
- The permission for the ~/.ssh and ~/.ssh/authorized_keys are incorrect
- Security policies on the remote server prohibit the login
The first two is easy to figure out. Below we will talk more about the possible security policy causes. The first thing to resolve the problem is to enable the debugging. On client side, you can run ssh command with -v or -vv. The more v you put, the more debug messages you get. On the server side, you can run the sshd service with -d or -dd option, the more d you put, the more debug message you get.
ssh user1@[hostname] -vvv
/usr/sbin/sshd -ddd
The debug message looks like :
$ ssh postman@192.168.56.150 -vvv OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014 debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.56.150 [192.168.56.150] port 22. debug1: Connection established. debug3: Incorrect RSA1 identifier debug3: Could not load "/c/Users/kepi/.ssh/id_rsa" as a RSA1 public key debug1: identity file /c/Users/kepi/.ssh/id_rsa type -1 debug1: identity file /c/Users/kepi/.ssh/id_rsa-cert type -1 debug3: Incorrect RSA1 identifier debug3: Could not load "/c/Users/kepi/.ssh/id_dsa" as a RSA1 public key debug1: identity file /c/Users/kepi/.ssh/id_dsa type -1 debug1: identity file /c/Users/kepi/.ssh/id_dsa-cert type -1 debug1: identity file /c/Users/kepi/.ssh/id_ecdsa type -1 debug1: identity file /c/Users/kepi/.ssh/id_ecdsa-cert type -1 debug1: identity file /c/Users/kepi/.ssh/id_ed25519 type -1 debug1: identity file /c/Users/kepi/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.9 debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.9 pat OpenSSH_5* compat 0x0c000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "192.168.56.150" from file "/c/Users/kepi/.ssh/known_hosts" debug3: load_hostkeys: found key type ECDSA in file /c/Users/kepi/.ssh/known_hosts:17 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2 -nistp384,ecdsa-sha2-nistp521 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received
When issue happens, you should read through the debug message and see what's going wrong.
On the server side, there are a few locations you would like to look into when issue happens.
/etc/ssh/sshd_config
This is the ssh server config file, it defines some rules for what the server will do. There are some options defining what users can login and how they can login.
- PubkeyAuthentication : Whether public key authentication is allowed
- PermitRootLogin : Whether root account is permitted. Set to no if root is now allowed. Check this option when login to root account.
- AuthorizedKeysFile : The autorized key file location. The default is at ~/.ssh/authorized_keys.
- AllowUsers/DenyUsers : Allow or deny users from login
- AllowGroups/DenyGroups : Allow or deny groups from login
/etc/security/user
On AIX, there is a security user file which can also define rules for login. It may have something like :
root:
admin = true
SYSTEM = "files"
loginretries = 4
account_locked = false
histsize = 8
minage = 0
This file needs to be checked as well to see whether an user is allowed or denied if on AIX.
