From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH 1/2] sshd_config: Do not set defaults explicitly
Date: Mon, 03 Feb 2020 17:42:44 +0000 [thread overview]
Message-ID: <E331AA5F-9A82-4FF2-A1BC-BDD1BCE40AC7@ipfire.org> (raw)
In-Reply-To: <649f26eb-cbe0-d476-204e-63ba888f10aa@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 6493 bytes --]
Hi,
> On 3 Feb 2020, at 17:24, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>
> Hello Michael,
>
> thanks for your reply.
>
> Since the Unbound configuration patch (https://patchwork.ipfire.org/patch/2710/)
> is based on the same motivation than this one, I am a bit surprised by your Reviewed-by
> tag on it. :-)
Yeah I could not remember if I wrote this email and waiting for a reply kind of timed out :)
> Breaking productive environment is a latter weak point to me, as keeping configuration
> statements/directives removed in the upstream may or may not cause the same effect.
> Worse, there may be good reasons for changing upstream defaults which we should track
> closely due to security considerations. On the other hands, relying on third parties
> is a bad idea when it comes to security - not to mention personal aversions against
> relying something or someone in general...
>
> In the end, I figure it is less worse to have a shorter configuration which takes less
> disk space and is easier to review and audit. You are right, the downside of this is
> to rely on other people's opinion of security and interoperability.
Disk space? We are saying bytes. As long as we are shipping half a gigabyte of firmware for outdated SCSI controllers, this won’t really help you much.
-Michael
P.S. I suppose we should just go ahead with this then:
Reviewed-by: Michael Tremer <michael.tremer(a)ipfire.org>
>
> Thanks, and best regards,
> Peter Müller
>
>> Hello,
>>
>> I am not 100% sure if I like this change.
>>
>> Simply because of defaults changing in software. Although we generally want to follow upstream this might break installations.
>>
>> Do we not see this as a danger?
>>
>> I would prefer to have shorter configurations, but not breaking production is more important.
>>
>> -Michael
>>
>>> On 20 Jan 2020, at 20:04, Peter Müller <peter.mueller(a)ipfire.org> wrote:
>>>
>>> In order to keep configurations as small as possible and to make them
>>> easier to read/audit, this patch omits all default configuration in the
>>> OpenSSH server configuration file.
>>>
>>> Further, it mentions where to refer for the full documentation.
>>>
>>> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org>
>>> ---
>>> config/ssh/sshd_config | 62 ++++++++++++++++----------------------------------
>>> 1 file changed, 20 insertions(+), 42 deletions(-)
>>>
>>> diff --git a/config/ssh/sshd_config b/config/ssh/sshd_config
>>> index a248c4906..bea5cee53 100644
>>> --- a/config/ssh/sshd_config
>>> +++ b/config/ssh/sshd_config
>>> @@ -1,81 +1,59 @@
>>> -# ultra-secure OpenSSH server configuration
>>> +# OpenSSH server configuration file for IPFire
>>> +#
>>> +# The full documentation is available at: https://man.openbsd.org/sshd_config
>>> +#
>>>
>>> -# only allow version 2 of SSH protocol
>>> +# Only allow version 2 of SSH protocol
>>> Protocol 2
>>>
>>> -# listen on port 22 by default
>>> +# Listen on port 22 by default
>>> Port 22
>>>
>>> -# listen on these interfaces and protocols
>>> -AddressFamily any
>>> +# Listen on every interface and IPv4 only
>>> +AddressFamily inet
>>> ListenAddress 0.0.0.0
>>>
>>> -# limit authentication thresholds
>>> +# Limit authentication timeout to 30 seconds
>>> LoginGraceTime 30s
>>> -MaxAuthTries 6
>>>
>>> -# limit maximum instanctes to prevent DoS
>>> +# Limit maximum instanctes to prevent DoS
>>> MaxStartups 5
>>>
>>> -# ensure proper logging
>>> -SyslogFacility AUTH
>>> -LogLevel INFO
>>> -
>>> -# enforce permission checks before a login is accepted
>>> -# (prevents damage because of hacked systems with world-writeable
>>> -# home directories or similar)
>>> -StrictModes yes
>>> -
>>> -# only allow safe crypto algorithms (may break some _very_ outdated clients)
>>> -# see also: https://stribika.github.io/2015/01/04/secure-secure-shell.html
>>> +# Only allow safe crypto algorithms (may break some _very_ outdated clients)
>>> +# 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,aes128-gcm(a)openssh.com,aes256-ctr,aes192-ctr,aes128-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 only
>>> -Compression delayed
>>> -
>>> -# only allow cryptographically safe SSH host keys (adjust paths if needed)
>>> +# 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 by default
>>> +# Only allow login via public key by default
>>> PubkeyAuthentication yes
>>> PasswordAuthentication no
>>> ChallengeResponseAuthentication no
>>> -PermitEmptyPasswords no
>>>
>>> -# permit root login as there is no other user in IPFire 2.x
>>> +# Permit root login as there is no other user in IPFire 2.x
>>> PermitRootLogin yes
>>>
>>> -# ignore user ~/.rhost* files
>>> -IgnoreRhosts yes
>>> -
>>> -# ignore user known hosts file
>>> +# Ignore user ~/.ssh/known_hosts file
>>> IgnoreUserKnownHosts yes
>>>
>>> -# ignore user environments
>>> -PermitUserEnvironment no
>>> -
>>> -# do not allow any kind of forwarding (provides only low security)
>>> +# 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
>>>
>>> -# detect broken sessions by sending keep-alive messages to
>>> -# clients (both via TCP and SSH)
>>> -TCPKeepAlive yes
>>> +# Detect broken sessions by sending keep-alive messages to clients via SSH connection
>>> ClientAliveInterval 10
>>>
>>> -# close unresponsive SSH sessions which fail to answer keep-alive
>>> +# Close unresponsive SSH sessions which fail to answer keep-alive
>>> ClientAliveCountMax 6
>>>
>>> -# add support for SFTP
>>> +# Add support for SFTP
>>> Subsystem sftp /usr/lib/openssh/sftp-server
>>>
>>> # EOF
>>> --
>>> 2.16.4
>>
next prev parent reply other threads:[~2020-02-03 17:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5B6C1246-8810-4DE7-B67F-2CEAE0BA2597@ipfire.org>
2020-02-03 17:24 ` Peter Müller
2020-02-03 17:42 ` Michael Tremer [this message]
2020-01-20 20:04 Peter Müller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E331AA5F-9A82-4FF2-A1BC-BDD1BCE40AC7@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox