Unable to SSH after securing Pi

Question

The questions I have found so far do not seem to satisfy my problem (e.g. I've tried the steps in them to no avail).

I'm in the process of securing a Raspberry Pi, following this guide: https://makezine.com/2017/09/07/secure-your-raspberry-pi-against-attackers/ Everything has gone well until the portion on SSH, specifically changing the SSH config to include the following:

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile ~/.ssh/authorized_keys

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

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

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

UsePAM no

I generated a public and private key pair using ssh-keygen on my local machine (running Kubuntu 18.04), placed the content of the public key in /home/myuser/.ssh/authorized_keys on the Pi, and ran the following on the Pi:

chmod 0600 ~/.ssh/authorized_keys
chmod 0700 ~/.ssh

The idea was to disallow logging in without that key. However, when logging in the following occurs:

ssh rpi@device
rpi@device: Permission Denied (publickey)

I have tried both pointing my configuration to the IdentityFile in ~/.ssh/config as well as passing it in with the -i option, both report the same error. I can attach the entire -vvv logs if requested, but the relevant sections (I think?) are:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:6IDQyb1F0xEgpz6tQzsp102G0ZB0d9ug3buR6ep7Mk4 /home/ericsilk/Documents/ProjectFolder/utility_scripts/ssh_keys/rpi_id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
rpi@device: Permission denied (publickey).

I have also followed the suggestions in the top respoonse to this question: https://askubuntu.com/questions/311558/ssh-permission-denied-publickey

I'm happy to post anything else that may be of use debugging things.

Edit: I've changed the rather generic "username@hostname" to a hopefully more readable "rpi@device". In response to the requests in the comments, the entry in my local machine for ~/.ssh/config is:

Host device
    User rpi
    PubKeyAuthentication yes
    IdentityFile ~/Documents/ProjectFolder/utility_scripts/ssh_keys/rpi_id_rsa

The /etc/ssh/sshd_config on the Pi looks like this:

#ListenAddress ::

#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 2m
PermitRootLogin no
StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

PubkeyAuthentication yes

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

#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 no
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 no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#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

The (redacted) contents of ~/.ssh/authorized_keys is:

ssh-rsa LONG_ALPHANUMERIC_STRING ericsilk@mylocaldesktop

I do also want to clarify that SSH was working before, but after these changes is not.

Answer 1

Your configuration looks a bit strange by fiddling this and that. By default we do not need a ~/.ssh/config file. For your needs it is also better to enable security system wide and not only for the user ericsilk with this config file. If it works you may consider to improve security by disabling ssh in general but enable it only for one user. This seems to be the intention to use a user specific config file but that should be a second step when ssh works. The ssh client is looking for the private key at /home/ericsilk/Documents/ProjectFolder/utility_scripts/ssh_keys/username_id_rsa, what's uncommon and improve complexity.

For reference I use Raspbian Stretch Lite 2018-10-09. Here is an accepted answer to use public key authentication without protecting the private key with a password: How to ssh without needing a password. But because you want to be as secure as possible we have to protect the use of the private key with a password. Please don't confuse this password with an authentication password to the ssh server. The password is only to protect the usage of the private key. Authentication is made with the private key. To reduce confusing I do not use any helpers like ssh-copy-id. Here is a configuration that works on my RasPi. On the management computer start with (if you already have a key pair id_ecdsa/id_ecdsa.pub save them before):

mngmt ~$ mkdir -m 700 ~/.ssh
mngmt ~$ ssh-keygen -N 'verySecurePassword' -f ~/.ssh/id_ecdsa -t ecdsa -b 521

This will give you a keypair id_ecdsa as private key and id_ecdsa.pub as public key in ~/.ssh/. Now on your client RasPi login as a user and create also:

rpi ~$ mkdir -m 700 ~/.ssh

and copy id_ecdsa.pub from the management computer to ~/.ssh/authorized_keys on the client RasPi and enable ssh server with:

rpi ~$ sudo systemctl --now enable ssh.service

Check with a simple ssh from your management computer if it works by executing /bin/hostname on the client. After entering the password to enable use of the private key id_ecdsa, that should return the hostname of the RasPi:

mngmt ~$ ssh username@raspberrypi hostname
Enter passphrase for key '/home/mngmtuser/.ssh/id_ecdsa':
raspberrypi
mngmt ~$

If it works then you can disable password authentication on the RasPi by setting:

PasswordAuthentication no

in /etc/ssh/sshd_config.

Please take care about your private key id_ecdsa. Everyone owning this file have access to your clients if he crack the password you have given to protect it's usage.

Answer 2

Many of us use PubkeyAuthentication. Assuming you have created valid keys and properly setup ~/.ssh/authorized_keys the ONLY thing you NEED to do is change

PubkeyAuthentication yes

After this is working you can THEN disable PasswordAuthentication

NOTE I suspect your problem is related to the AuthorizedKeysFile line (which is commented out in the default /etc/ssh/sshd_config (and in my working copy)

#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

My comment about "questionable settings" refers to enabling root password (which is NOT Debian practice) and creating a user without groups - which will result is a seriously degraded experience. By all means create a Restricted user, but leave a normal Administrator.

There is no need to disable PAM.