Key Authentication Not Working in Ubuntu SSH Server

Question

I'm trying to setup my ssh server for password less login (key login) and it does not work. I have tried different permission, played around with different usernames. same results. It continue to ask me for a password. So I turned on verbose during login and I'm posting the output here, but first let me tell you how I configured

mkdir .ssh 
ssh-keygen -t rsa -b 4096
#this created the id_rsa (private) and id_rsa.pub (public)
#then I copied the pub key over to server but first created .ssh on server
mkdir .ssh
#copy key
scp ~/.ssh/id_rsa.pub [email protected]:/home/user/.ssh

cat .ssh/id_rsa.pub >> .ssh/authorized_keys

then I changed permissions to remote .ssh dir
chmod 0700 .ssh
chmod 0600 .ssh/*

try connecting and still ask for password... what am I missing here

 ssh [email protected] -v
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.137.5 [192.168.137.5] port 22.
debug1: Connection established.
debug1: identity file /home/jsmith/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/jsmith/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.1
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.137.5:22 as 'jsmith'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:fki8+w3jFMEPfWs1Onmyg/F49v5gmkJw+IQPIO04dFE
debug1: Host '192.168.137.5' is known and matches the ECDSA host key.
debug1: Found key in /home/jsmith/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:Z25KcC58I5C8/mvtJmlRDL5AOZ5cIYXY8nbgfIABFVU /home/jsmith/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 535
Enter passphrase for key '/home/jsmith/.ssh/id_rsa':
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.137.5 ([192.168.137.5]:22).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype [email protected] want_reply 0
debug1: Remote: /home/jsmith/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: /home/jsmith/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: Sending env LANG = C.UTF-8
Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-42-generic x86_64)

 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage

  System information as of Fri 07 Aug 2020 11:54:16 PM UTC

  System load:  0.03              Processes:               137
  Usage of /:   72.2% of 3.87GB   Users logged in:         1
  Memory usage: 14%               IPv4 address for enp0s3: 192.168.137.5
  Swap usage:   0%

 * Are you ready for Kubernetes 1.19? It's nearly here! Try RC3 with
   sudo snap install microk8s --channel=1.19/candidate --classic

   https://microk8s.io/ has docs and details.

0 updates can be installed immediately.
0 of these updates are security updates.


Last login: Fri Aug  7 23:50:02 2020 from 192.168.137.1

Answer 1

The output of ssh [email protected] -v reveals you were at no point asked for the password to the remote system. You were however asked for the passphrase for the key and then the key worked:

Enter passphrase for key '/home/jsmith/.ssh/id_rsa':
debug1: Authentication succeeded (publickey).

You apparently specified a non-empty passphrase while creating the key. And I guess the passphrase is the same as your password to the remote server. You may have thought the key will work by storing the password you can otherwise use without a key; and with this thought you typed the password as a passphrase. Upon connecting you were asked for the passphrase, and since it's identical to the password, you think you were asked for the password and you think you authenticated with the password and therefore it worked.

This is what really happens: Your private key is stored as encrypted. When you try to connect, you need to provide the passphrase to decrypt the key on your local machine, so the key can be used to authenticate you. The passphrase is not revealed to the remote server, nor it is directly used to authenticate you. It is only used to decrypt your private key and then the decrypted key is used.

The passphrase and the password are different concepts. During creation of a key you can use a passphrase that has nothing to do with your password. To be able to authenticate without typing anything, create a key with an empty passphrase.

Your key itself seems to work fine. There is no need to create another key (this time with an empty passphrase) because you can remove the passphrase from the current key:

# on the machine where the private key is, not on the server
ssh-keygen -p

The program will prompt you for the key file location (/home/jsmith/.ssh/id_rsa will probably be the default, so it will be enough to press Enter), for the old passphrase and (twice) for the new one. Make the new passphrase empty by just hitting Enter when prompted. Then you should be able to connect to the server without typing any password or passphrase.

Answer 2

If the user has RSA key you should provide the private key (identity file) when login, using the syntax: ssh -i /local/path/to/private/key user@destinationIP