Understand why my ssh configuration does not allow passwordless login?

I thought that the PasswordAuthentication directive was responsible for letting you log in using only the ssh key pair (local private key / remote public key). I am able to log in using my password with the configuration shown below but the minute I change PasswordAuthentication yes to PasswordAuthentication no I get a error.

[email protected]< ip address here >: Permission denied (publickey).

Versions Information

[email protected]:~$ ssh -V
OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n  7 Dec 2017  
Server built: 2019-07-16T18:14:45  
[email protected]:~$ lsb_release -a  
…  
Distributor ID: Ubuntu  
Description: Ubuntu 18.04.3 LTS  
Release: 18.04  
Codename: bionic  

Current config with own comments too..

#       $OpenBSD: sshd_config,v 1.101 2017/03/14 07:19:07 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22

 AddressFamily inet
#ListenAddress 0.0.0.0  # <--  Is that default to have two ??
#ListenAddress ::  # <--  Is that default to have two ??

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

 LoginGraceTime 1m
 PermitRootLogin no

#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes  # <--  Thought that was default "yes"

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes  # <--  THERE IT IS! When change to no login fails

#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and

# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem       sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server

Can anyone spot this what is the problem?
Thanks in advance for help.

Jake

4 Replies

Linode Staff

Hey there,

It seems to me that either your ~/.ssh/authorized_keys file isn't configured properly or your client isn't configured to use your private key.

It is possible that either the permissions for the authorized_keys file are not set properly, or the contents of the file may be off.

I've had trouble a few times where my pub key wasn't working because authorized_keys didn't like the line breaks or syntax from the key output of the programs I've used to generate them.

Check out the Harden SSH Access section of our How to Secure Your Server guide and make sure you've followed all the steps to setup SSH access.

For a permissions issue, this command should fix the problem:
sudo chmod -R 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

If that doesn't fix it, make sure that your public key in the authorized_keys file doesn't contain any extra whitespace, and your whole key entry should be on a single line. It should look like this:

ssh-rsa AAAABblahblahblah

You'll also be able to tell if your key is working when you aren't prompted for a password, even when passwords are enabled.

If those steps don't work for you, it is possible that the client you're using to connect via ssh is not configured to use your private key to connect. If you're on a Mac, you can add your private key to the agent by running the following terminal command:

ssh-add -K ~/.ssh/id_rsa

For Windows you'll have to find documentation depending upon what client you're using to connect to see where you'll need to add your private key.

If you're using PuTTy, you find the key selection box in Connection > SSH > Auth and use the Browse button to select your key file.

Hopefully this gets you up and running.

@_Brian -thanks for the response.

The problem arose with a new linode / setup. It had been working with a previous linode fine.

You'll also be able to tell if your key is working when you aren't prompted for a password, even when passwords are enabled.

I also recall that the above was true for me in previous linodes.

I'll post back with what worked in case someone sees this in the future.

Thanks
Jake

I ran

$ sudo chmod -R 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

and didn't see any observable change in the permissions from what they had been. I use the following to check that.

$ ls -al ~/
$ ls -al ~/.ssh

Update:

Well fellas we may have found the problem (at least in this case)..

$ nano ~/.ssh/authorized_keys

Nothing, zero, nada no content! It is completely empty.

I was so surprised (since I specifically recollect adding the key contents to it) that I had to run..

$ less ...

and

$ cat ...

as well.


Yep - that was it!

There were no contents in my authorized keys file. Placing the contents inside, changing the sshd_config, and restarting ssh it has been a success.

@_Brian -really appreciate the nudge. I guess sometimes that's all it takes.

fwiw..

$ cat ~/.ssh/authorized_keys # output will be all one line
# copy the output from the command line
$ nano ~/.ssh/authorized_keys
# paste the content and save the file

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct