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(a)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(a)libssh.org,diffie-hellman-group-exchange-
> sha256
> +Ciphers chacha20-poly1305(a)openssh.com,aes256-gcm(a)openssh.com,aes256-ctr
> +MACs hmac-sha2-512-etm(a)openssh.com,hmac-sha2-256-etm(a)openssh.com,
> umac-128-etm(a)openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128(a)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