[1/2] add hardened SSH server configuration

  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
  

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
  

Hello Michael,

> 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.
Is 30 seconds enough (default setting in IPFire 2.x)?
> 
>> +MaxSessions 5
> 
> Per user? Why?
Because most users do not connect to a machine multiple times - at least not more
than five times. Many active logins for one account are a clear indicator of compromise,
especially if the account is only secured by a password.

OpenSSH default is 10, but this seems too high for me.
> 
>> +# 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.
All right, comment will be adjusted in second version of this patch. This slipped my mind.
> 
>> +# only allow safe crypto algorithms (may break some _very_ outdated clients)
> 
> *How* outdated? From the 90s or last year?
I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most
recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more
or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH)
can be used.

In case a system is older than that, I doubt it can be considered secure anymore.
> 
>> +# 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
Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more
for compression is more secure as it avoids possible zlib vulnerabilities
to unauthenticated users (Simple, but I was unaware of it.):

>     Added a new compression method that delays the start of zlib
>     compression until the user has been authenticated successfully. 
>     The new method ("Compression delayed") is on by default in the 
>     server. This eliminates the risk of any zlib vulnerability 
>     leading to a compromise of the server from unauthenticated users.

Compression does not seem to have security impact to a SSH connection itself.

Because of the security risk described above, I'd prefer "delayed" as a
setting to this in a second version of the patch.
> 
>> [...]>> +# EOF
By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376b284a0f98609e19e
sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?

Best regards,
Peter Müller
> 
> -Michael
> -- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
		-- bugtraq
  

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2018-08-20 at 17:06 +0200, Peter Müller wrote:
> Hello Michael,
> 
> > 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.
> 
> Is 30 seconds enough (default setting in IPFire 2.x)?

Yes I think so. I don't even see that there is a huge desire in a very
low limit. This only allows to brute-force a little bit faster.
However, the keys should be virtually un-brute-force-able and therefore
dividing the time you need to search by 10 isn't making any difference
in practise.

> > 
> > > +MaxSessions 5
> > 
> > Per user? Why?
> 
> Because most users do not connect to a machine multiple times - at least not more
> than five times. Many active logins for one account are a clear indicator of compromise,
> especially if the account is only secured by a password.

Well, true. But I often use an IPFire system as a jump host and for
that open multiple connections.

> OpenSSH default is 10, but this seems too high for me.

This sounds good to me.

> > 
> > > +# 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.
> 
> All right, comment will be adjusted in second version of this patch. This slipped my mind.
> > 
> > > +# only allow safe crypto algorithms (may break some _very_ outdated clients)
> > 
> > *How* outdated? From the 90s or last year?
> 
> I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most
> recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more
> or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH)
> can be used.

Your first comment stated *very* outdated. One year isn't outdated.

PuTTY doesn't have an update mechanism and therefore will probably be
installed once and never updated on the average admin's machine.

> In case a system is older than that, I doubt it can be considered secure anymore.

Because of? Using RSA?

> > 
> > > +# 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
> 
> Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more
> for compression is more secure as it avoids possible zlib vulnerabilities
> to unauthenticated users (Simple, but I was unaware of it.):

That is a different attack then.

The OpenVPN issue is about a known-plaintext attack which could also be
done (in theory - I think) on SSH unless they add any random padding
which would increase overhead and reduce the bandwidth savings of the
compression.

> >     Added a new compression method that delays the start of zlib
> >     compression until the user has been authenticated successfully. 
> >     The new method ("Compression delayed") is on by default in the 
> >     server. This eliminates the risk of any zlib vulnerability 
> >     leading to a compromise of the server from unauthenticated users.
> 
> Compression does not seem to have security impact to a SSH connection itself.
> 
> Because of the security risk described above, I'd prefer "delayed" as a
> setting to this in a second version of the patch.

That doesn't have anything to do with the stated attack, so I guess it
doesn't make much of a difference to me.

> > 
> > > [...]>> +# EOF
> 
> By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376b284a0f98609e19e
> sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?

22 is now default, but of course the switch on the webUI should still
work.

- -Michael

> 
> Best regards,
> Peter Müller
> > 
> > -Michael
> > -- 
> 
> Microsoft DNS service terminates abnormally when it recieves a response
> to a DNS query that was never made.  Fix Information: Run your DNS
> service on a different platform.
> 		-- bugtraq
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlt+u/oACgkQgHnw/2+Q
CQcDGBAAgBF/b0WDpQ1Lds+KDTKlvEKo2+WInK1+0ZGKeB88+CFL40RAkwLjG1VT
0k7DJ4+cnHn+114qhnrqxJ9LXzxchIE+BIJFcfD+dDhWueNjPZUWSCXznPPxJatO
iXZm8ILlKwUkSKgL5apUvBxMe4Sk68zdwV0vSMCUh3PziRgAHA/d7txp0391oZU1
BhWD4mKYGo9ZVYywIk0oXyttLB0CNK+YT0WYP3rwy7/K5yj+iC9d8lqHLj00YwYB
iNfswwPG+E/MbKxsJdqMfu4Glco8KL+MAs/7Nke4Ms1vWGktmAzHR1dIk9Z6A+59
MtkcvojVfoOJ6pI5AVDKIQ66tn08X1dEo8vnHuG6OlZcrtyC6wWAXGn6BqiX/IJS
rCYoBteiCV8EJI0SZgk2hUSyLAfPpkt4KBko42FIgO4oHsASofe51ALYceKOSHp1
6TJBQ1JdWpPc1cl0lQxhRGcGXQ9n7gfE6mXY2NdNEFh9V5M8kTO/CafGgcwwHdF/
RF7cjYGw3BAei5B9e11qiIzqIe5SV7EB0xMjDfzQeloIOl+6SQQdzv0U3Kl/PNg5
WXraj6HuRM5KYLmSW5BXtV3ujBqnaVRH8YZ9/Hij7MFKN7eK6Kt8yzFqtLUiPywP
9lClzdt6No5g/YBB97eKMYBgFuHnTM9d/uTmtR/RBk6ItmRCgXc=
=+HiS
-----END PGP SIGNATURE-----
  

Hello Michael,

> [snip]
>>>> +
>>>> +# 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.
> 
>> Is 30 seconds enough (default setting in IPFire 2.x)?
> 
> Yes I think so. I don't even see that there is a huge desire in a very
> low limit. This only allows to brute-force a little bit faster.
> However, the keys should be virtually un-brute-force-able and therefore
> dividing the time you need to search by 10 isn't making any difference
> in practise.
Provided people are using SSH keys, yes. We have had that discussion.
> 
>>>
>>>> +MaxSessions 5
>>>
>>> Per user? Why?
> 
>> Because most users do not connect to a machine multiple times - at least not more
>> than five times. Many active logins for one account are a clear indicator of compromise,
>> especially if the account is only secured by a password.
> 
> Well, true. But I often use an IPFire system as a jump host and for
> that open multiple connections.
Hm, have you tried something like this for jumping (snip from ~/.ssh/config):

Host *.ipfire.org
	ProxyCommand ssh -q [proxy IP] nc %h %p

It avoids open SSH sessions on systems, which need some scheduled downtime
entries in my network (paranoia...), so I am very happy with this. :-)
> 
>> OpenSSH default is 10, but this seems too high for me.
> 
> This sounds good to me.
All right, I will use this value.
> 
>>>
>>>> +# 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.
> 
>> All right, comment will be adjusted in second version of this patch. This slipped my mind.
>>>
>>>> +# only allow safe crypto algorithms (may break some _very_ outdated clients)
>>>
>>> *How* outdated? From the 90s or last year?
> 
>> I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most
>> recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more
>> or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH)
>> can be used.
> 
> Your first comment stated *very* outdated. One year isn't outdated.
Talking about software updates, one year is _very_ outdated. Especially
if you are running Windows. Assumption here is if a client cannot use a
service because it is too old to support the cryptography required, it did
not receive other important updates, too.
> 
> PuTTY doesn't have an update mechanism and therefore will probably be
> installed once and never updated on the average admin's machine.
You are right and I gnashingly agree in case of normal distributions. Talking
about a firewall system, I do not. Similar to TLS 1.2, which we enforced a few
Core Updates ago, we should enforce strong cryptography for SSH.

If an admin's machine does not support that because it is outdated, I couldn't care less.
> 
>> In case a system is older than that, I doubt it can be considered secure anymore.
> 
> Because of? Using RSA?
Lack of updates (see above). RSA is a smaller (performance) problem in my eyes.
> 
>>>
>>>> +# 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
> 
>> Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more
>> for compression is more secure as it avoids possible zlib vulnerabilities
>> to unauthenticated users (Simple, but I was unaware of it.):
> 
> That is a different attack then.
ACK. Sorry for mixing things up here.
> 
> The OpenVPN issue is about a known-plaintext attack which could also be
> done (in theory - I think) on SSH unless they add any random padding
> which would increase overhead and reduce the bandwidth savings of the
> compression.
> 
>>>     Added a new compression method that delays the start of zlib
>>>     compression until the user has been authenticated successfully. 
>>>     The new method ("Compression delayed") is on by default in the 
>>>     server. This eliminates the risk of any zlib vulnerability 
>>>     leading to a compromise of the server from unauthenticated users.
> 
>> Compression does not seem to have security impact to a SSH connection itself.
> 
>> Because of the security risk described above, I'd prefer "delayed" as a
>> setting to this in a second version of the patch.
> 
> That doesn't have anything to do with the stated attack, so I guess it
> doesn't make much of a difference to me.
> 
>>>
>>>> [...]>> +# EOF
> 
>> By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376b284a0f98609e19e
>> sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
> 
> 22 is now default, but of course the switch on the webUI should still
> work.
Okay, thanks. Will send in a second version of this patch.

Best regards,
Peter Müller
> [snip]-- 
Microsoft DNS service terminates abnormally when it recieves a response
to a DNS query that was never made.  Fix Information: Run your DNS
service on a different platform.
		-- bugtraq
  

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, 2018-08-23 at 21:37 +0200, Peter Müller wrote:
> Hello Michael,
> 
> > [snip]
> > > > > +
> > > > > +# 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.
> > > Is 30 seconds enough (default setting in IPFire 2.x)?
> > 
> > Yes I think so. I don't even see that there is a huge desire in a very
> > low limit. This only allows to brute-force a little bit faster.
> > However, the keys should be virtually un-brute-force-able and therefore
> > dividing the time you need to search by 10 isn't making any difference
> > in practise.
> 
> Provided people are using SSH keys, yes. We have had that discussion.

Or very long passwords.

> > 
> > > > 
> > > > > +MaxSessions 5
> > > > 
> > > > Per user? Why?
> > > Because most users do not connect to a machine multiple times - at least not more
> > > than five times. Many active logins for one account are a clear indicator of compromise,
> > > especially if the account is only secured by a password.
> > 
> > Well, true. But I often use an IPFire system as a jump host and for
> > that open multiple connections.
> 
> Hm, have you tried something like this for jumping (snip from ~/.ssh/config):
> 
> Host *.ipfire.org
> 	ProxyCommand ssh -q [proxy IP] nc %h %p
> 
> It avoids open SSH sessions on systems, which need some scheduled downtime
> entries in my network (paranoia...), so I am very happy with this. :-)

No.

> > > OpenSSH default is 10, but this seems too high for me.
> > 
> > This sounds good to me.
> 
> All right, I will use this value.
> > 
> > > > 
> > > > > +# 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.
> > > All right, comment will be adjusted in second version of this patch. This slipped my mind.
> > > > 
> > > > > +# only allow safe crypto algorithms (may break some _very_ outdated clients)
> > > > 
> > > > *How* outdated? From the 90s or last year?
> > > I successfully tested this with OpenSSH 6.6 (released 15-03-2014) and most
> > > recent PuTTY 0.70 (released 08-07-2017). This leads me to the assumption more
> > > or less up to date clients (<= 1 year for PuTTY and <= 4 years for OpenSSH)
> > > can be used.
> > 
> > Your first comment stated *very* outdated. One year isn't outdated.
> 
> Talking about software updates, one year is _very_ outdated. Especially
> if you are running Windows. Assumption here is if a client cannot use a
> service because it is too old to support the cryptography required, it did
> not receive other important updates, too.
> > 
> > PuTTY doesn't have an update mechanism and therefore will probably be
> > installed once and never updated on the average admin's machine.
> 
> You are right and I gnashingly agree in case of normal distributions. Talking
> about a firewall system, I do not. Similar to TLS 1.2, which we enforced a few
> Core Updates ago, we should enforce strong cryptography for SSH.
> 
> If an admin's machine does not support that because it is outdated, I couldn't care less.

I do care here. In this order: Security, Interoperability, Usability.

> > > In case a system is older than that, I doubt it can be considered secure anymore.
> > 
> > Because of? Using RSA?
> 
> Lack of updates (see above). RSA is a smaller (performance) problem in my eyes.

So if there is a reason why RSA should not be used here anymore I would
agree to drop it. Now, we are just diminishing interoperability without
any gain in security. There is no point in that.

Performance? How many logins do you perform a second? Thousands? This
matters for HTTPS maybe with hundreds or thousands of handshakes per
second but not for SSH.

If you disable RSA in your client, you will still use the new fancy
crypto stuff and save a couple of nanoseconds :)

> > 
> > > > 
> > > > > +# 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
> > > Not really. https://www.openssh.com/txt/release-4.2 states "delayed" more
> > > for compression is more secure as it avoids possible zlib vulnerabilities
> > > to unauthenticated users (Simple, but I was unaware of it.):
> > 
> > That is a different attack then.
> 
> ACK. Sorry for mixing things up here.
> > 
> > The OpenVPN issue is about a known-plaintext attack which could also be
> > done (in theory - I think) on SSH unless they add any random padding
> > which would increase overhead and reduce the bandwidth savings of the
> > compression.
> > 
> > > >     Added a new compression method that delays the start of zlib
> > > >     compression until the user has been authenticated successfully. 
> > > >     The new method ("Compression delayed") is on by default in the 
> > > >     server. This eliminates the risk of any zlib vulnerability 
> > > >     leading to a compromise of the server from unauthenticated users.
> > > Compression does not seem to have security impact to a SSH connection itself.
> > > Because of the security risk described above, I'd prefer "delayed" as a
> > > setting to this in a second version of the patch.
> > 
> > That doesn't have anything to do with the stated attack, so I guess it
> > doesn't make much of a difference to me.
> > 
> > > > 
> > > > > [...]>> +# EOF
> > > By the way: https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=16c31d10040db4f175642376b284a0f98609e19e
> > > sets 22 as default listen port for OpenSSH, so I did not include 222 anymore. Agreed?
> > 
> > 22 is now default, but of course the switch on the webUI should still
> > work.
> 
> Okay, thanks. Will send in a second version of this patch.
> 
> Best regards,
> Peter Müller
> > [snip]-- 
> 
> Microsoft DNS service terminates abnormally when it recieves a response
> to a DNS query that was never made.  Fix Information: Run your DNS
> service on a different platform.
> 		-- bugtraq
> 
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAlt/7/YACgkQgHnw/2+Q
CQdPNg/+IAdUX/6GUSrnWvu0JpQDCSs/VSlEm9alxiCiyEnbdRkQ5FsL5COfUAIC
30yME6yXKX07N7GK8pSNeu3jp9tAihfCF9W/trm20blgrfuoKPd6lamBywEWCZ4x
RRNYtiDXMM9eT7dSFHKolSJNgzMMKme6wG7NXzgLJH/Cy9PJAxrJaplyu2cmpkTT
aYHHW8SVNiUmnuOY/XD/2wCsvgk80X6AIczjt3i8q1ZS14NHqoKp8v4fBjwzELcZ
tGjnKBHFedhy9/7sLggx11ieusAehGxlk+R7l9fAKxHL8IcGKtTpvtcB+cYBUzze
RlAeo90xAaFk9mIv0W3i2MrBVWit1LMURiuUgkaQi3jJKr+TVlB7hqHiUjP+xVet
X5wPnAmIE0rKqKI9umc9rA7/1lykclYZ8qVpcLBMu4Zzy0XYz0/YCyGUahNqKywJ
YpyBzTOP6Ef2FoOqnpXQsDDJqNPqmSrtGgagA4ZyDylKPLi15rVHLGQMCI1AY+YR
lvqLgLkpcf9K3QCi7D2d54ttVc7PN68Gd05KlcdI+u8/a2T7rtr99yM2rFkHnsDE
i8S2TU72APO/qj9do4buW2c4IxqksOXuO8nlMkJaMK2C2RdavhYb41iXwBcnCFX0
R5yUMZsjhl64e4uZNEm6fxUygVcPdCgEUNVuycQvcQEGHgSxjzk=
=p1Lz
-----END PGP SIGNATURE-----