Hey,
On Sun, 2018-08-19 at 20:41 +0200, Peter Müller wrote:
In order to harden OpenSSH server in IPFire, using the upstream default configuration and edit it via sed commands in LFS file is error-prone and does not scale.
Thereof we ship a custom and more secure OpenSSH server configuration which is copied into the image during build time.
Fixes #11750 Fixes #11751 Partially fixes #11538
Signed-off-by: Peter Müller peter.mueller@link38.eu
config/ssh/sshd_config | 68 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 68 insertions(+) create mode 100644 config/ssh/sshd_config
diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config new file mode 100644 index 000000000..7acf48109 --- /dev/null +++ b/config/ssh/sshd_config @@ -0,0 +1,68 @@ +# ultra-secure OpenSSH server configuration
+# only allow version 2 of SSH protocol +Protocol 2
+# listen on these interfaces and protocols +AddressFamily any +ListenAddress 0.0.0.0 +ListenAddress ::
+# limit authentication thresholds +LoginGraceTime 20s +MaxAuthTries 3
Three is definitely too little. I have three versions of my key (RSA, ECDSA and Ed25519). After my client tried all of these, a password prompt won't be shown any more.
+MaxSessions 5
Per user? Why?
+# limit maximum instanctes +MaxStartups 5
+# ensure proper logging +SyslogFacility AUTH +LogLevel INFO
+# always turn on strict mode +StrictModes yes
The comment explains the option, but it should explain what it does. We have discussed that before in another thread to a patch that only enabled this.
+# only allow safe crypto algorithms (may break some _very_ outdated clients)
*How* outdated? From the 90s or last year?
+# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html +KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange- sha256 +Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes256-ctr +MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com, umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com
+# enable data compression after successful login +Compression yes
Is there any research on whether this still is safe?
See: https://bugzilla.ipfire.org/show_bug.cgi?id=11819
+# only allow cryptographically safe SSH host keys (adjust paths if needed) +HostKey /etc/ssh/ssh_host_ed25519_key +HostKey /etc/ssh/ssh_host_ecdsa_key +HostKey /etc/ssh/ssh_host_rsa_key
+# only allow login via public key +PubkeyAuthentication yes +PasswordAuthentication no +ChallengeResponseAuthentication no +PermitEmptyPasswords no +AuthenticationMethods publickey
+# ignore user ~/.rhost* files +IgnoreRhosts yes
+# ignore user known hosts file +IgnoreUserKnownHosts yes
+# ignore user environments +PermitUserEnvironment no
+# do not allow any kind of forwarding (provides only low security) +# some of them might need to be re-enabled if SSH server is a jump platform +X11Forwarding no +AllowTcpForwarding no +AllowAgentForwarding no +PermitTunnel no +GatewayPorts no +PermitOpen none
In the default configuration for the WebUI, TCP forwarding is enabled by default. So this is changed when SSH is being started for the first time.
+# close broken session (clients went offline, ...) automagically +TCPKeepAlive yes
+# EOF
-Michael