IBM Support

Automatic logins via SSH using public keys

Troubleshooting


Problem

SSH Automatic Login to the NPS server using Public Keys (Linux / UNIX) 

Diagnosing The Problem

You would like to SSH to the NPS server, confirm you are authorized securely, and login without using a password from a Linux / *nix client machine

Resolving The Problem

This document outlines how you can set up automatic logins via SSH using public keys. It addresses connecting from a Linux machine to the NPS server using OpenSSH. These instructions should be similar for other SSH clients on any *nix machines.

Also included are various troubleshooting methods in case something does not work the way it is expected to. This will not cover all situations, only the most common set up mistakes.

The expected result is the ability to SSH to the NPS server, confirm you are authorized, and log in without using a password.

The instructions assume the following information is true. If not, it needs to be corrected first.

In the examples:

  • client.machine.com is the remote computer you are using to connect to the NPS server.
  • nps.server.com is the NPS server that you are connecting to.
  • SSH between client.machine.com and nps.server.com is already possible.
  • client.machine.com resolves correctly to the IP address on both machines.
  • nps.server.com resolves correctly to the IP address on both machines.

Begin on the client machine (the one you want to connect to the NPS server). This example uses a client with Linux OS with a OpenSSH client. The work is done under the user's home directory. The example uses an RSA key that only works with the SSH2 protocol (which is what is used on the NPS server). It is considered more secure, and therefore preferred, to DSA.

On the client machine [client.machine.com]

Generate the key; do not enter a passphrase (just hit enter).

[user@client.machine.com ~/.ssh]$ ssh-keygen -t rsa
                        Generating public/private rsa key pair.
                        Enter file in which to save the key (/home/user/.ssh/id_rsa):
                        Enter passphrase (empty for no passphrase):
                        Enter same passphrase again:
                        Your identification has been saved in /home/user/.ssh/id_rsa.
                        Your public key has been saved in /home/user/.ssh/id_rsa.pub.
                        The key fingerprint is:
                        cd:2f:d5:f9:97:15:fb:4d:aa:9d:34:3e:ed:60:18:44 user@client.machine.com

Create a SSH config file so that you don't have to type this each time you connect. This is done in the ~/.ssh folder (which you are still in). If you are doing this for multiple servers, the file begins with Host x.x.x and the commands needed are listed below it; just repeat the block below and change the Host name.
    [user@client.machine.com ~/.ssh]$ vi config
    -------------------------------------------------
    Host nps.server.com
    User nz
    IdentityFile ~/.ssh/id_rsa
    -------------------------------------------------

Change the permissions on the config file:

The file permissions should look like:

The remote machine, the NPS Server, is a Red Hat Linux OS running Open SSH. You must configure the SSHD server and import the client machine's key.


On the remote NPS Server [nps.server.com]

As the root user on the NPS server edit the /etc/ssh/sshd_config file.

Locate the following lines in the file and uncomment or change the values to match:
    RSAAuthentication yes
    PubkeyAuthentication yes
    AuthorizedKeysFile .ssh/authorized_keys
    UsePAM no


As the root user restart ssh:

Login as the nz user:

If the .ssh directory does not exist in the home directory ( ~ ) then create it.

Check the permissions on this folder (even if it exists!). They should look like:
    drwx------ 2 nz nz 4096 Sep 28 07:04 .ssh

If they do not, correct it:

Add the client's public key to the authorized public keys on the server. Most sshd config files point to authorized_keys, so we make a soft link to the authorized_keys2 file. Permissions are important here so do not miss that step. Finally, remove the key you transfered (client.key.pub) as anyone who has access to this can impersonate the client machine.

Testing the changes

From the local machine, issue a connection to the remote NPS server via SSH:

If all has gone according to plan, then you will now be on the NPS server, logged in as nz, and in the nz user's home directory.

Troubleshooting

If, after following these instructions, you are still not able to log in automatically, some troubleshooting is necessary.

First, connect using the debug mode for the ssh client. Adding the flag -v gives you debug level 1. Adding -vv gives you Debug Level 2 and -vvv Debug Level 3. To get as much information as possible, issue the following:

[user@client.machine.com ~]$ ssh -vvv nps.server.com
OpenSSH_4.3p2 Debian-8ubuntu1, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /home/user/.ssh/config
debug1: Applying options for nps.server.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to nps.server.com [192.168.1.1] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /home/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug3: key_read: missing whitespace
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1
debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug1: An invalid name was supplied Configuration file does not specify default realm
debug1: An invalid name was supplied A parameter was malformed Validation error
debug1: An invalid name was supplied Configuration file does not specify default realm
debug1: An invalid name was supplied A parameter was malformed Validation error
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 143/256
debug2: bits set: 486/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 8
debug3: check_host_in_hostfile: filename /home/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 7
debug1: Host 'nps.server.com' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:8
debug2: bits set: 539/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/user/.ssh/id_rsa (0x800545d8)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: gssapi,publickey,keyboard-interactive,password
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied Configuration file does not specify default realm
debug1: An invalid name was supplied Configuration file does not specify default realm
debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password nz@nps23226's password:


The last line of this output shows that it is requesting a password. Although there are a few problems in this connection attempt, this effort is focused on the publickey part to determine what happened.

The last few lines indicate that there was a public key, it sent a publickey packet and then for some reason disabled the method and moved on to password authentication. This information indicates that the issue is on the NPS server, as the debug output recognized all the client setup information, used the publickey method and it didn't work.

Now investigate the NPS server.

This line indicates that our authorized_keys2 file has bad permissions. Do the following to check / correct this:
    cd ~/.ssh
    ls-lah authorized_keys2

Result is:
    -rwxrw-rw- 1 nz nz 1.5K Sep 28 16:41 authorized_keys2

These settings are too permissive and will cause automatic login to fail. Fix this by issuing the following:
    chmod 600 authorized_keys2

Now you see:
    ls -lah authorized_keys2
    -rw------- 1 nz nz 1.5K Sep 28 16:41 authorized_keys2

If there are any issues with following the guide, please double-check the instructions and use the debug mode / logs to help diagnose the issue.

If you are looking to do this setup using PuTTY from a Windows machine, refer to the document referenced below, How can I automate SSH logins from a Windows computer?

Related Information

Automate SSH logins from Windows

[{"Product":{"code":"SSULQD","label":"IBM PureData System"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":null,"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.0.0","Edition":"","Line of Business":{"code":"LOB10","label":"Data and AI"}}]

Historical Number

NZ931411

Document Information

More support for:
IBM PureData System

Software version:
1.0.0

Document number:
462007

Modified date:
17 October 2019

UID

swg21569685

Page Feedback