2

I'm using ssh on my linux box, I want to secure it to be as watertight as possible, only allowing ssh via ed25519 elliptic curve crypto sigs.

I thought I had it setup correctly, disabling password, no PAM, etc.

It seemed to be working properly but today I noticed I didn't have an authorised_keys file specified, and I had PubkeyAuthentication commented out.

Are these things implicitly set to yes when password auth is set to no?

Is this setup ok?

#       $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj 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 any
#ListenAddress 0.0.0.0
#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 prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication 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 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
Woodstock
  • 103
  • 1
  • 1
  • 10

1 Answers1

2

I am not sure, whether excluding all public key algorithms, except ed25519 is not being overzealous and it a good security strategy. Security StackExchange can certainly tell you more on the subject.

SSH default values are listed in the sshd_config manpage, but it is better to read the one on your system: for example Debian changes some upstream defaults. PubkeyAuthentication's default is yes and AuthorizedKeysFile's default is ~/.ssh/authorized_keys (American spelling).

Assuming you want to: disable all password-based authentication and use only ed25519 public key cryptography, taking into account upstream defaults you just need:

ChallengeResponseAuthentication no
#GSSAPIAuthentication no by default
#HostbasedAuthentication no by default
#KbdInteractiveAuthentication defaults to ChallengeResponseAuthentication
#KerberosAuthentication no by default
PasswordAuthentication no
#PubkeyAuthentication yes by default
PubkeyAcceptedKeyTypes ssh-ed25519
UsePAM yes

Disabling the use of PAM as a whole disables the use of the account and session PAM modules, which provide a better environment for the user. The auth PAM module will not be used anyway, since both password and challenge-response authentications are disabled.

Piotr P. Karwasz
  • 5,292
  • 2
  • 9
  • 20
  • Thanks you @Piotr. Why would using exclusive 25519 be over zealous? – Woodstock Dec 09 '19 at 22:08
  • As far as I know, the other public key algorithms are not broken (if the keys are large enough), but better ask on Security StackExchange. Also some elliptic curves may be weak, so I wouldn't trust exclusively ED25519. – Piotr P. Karwasz Dec 09 '19 at 22:14