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(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
> 
>> 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