From nobody Mon Jan 31 02:13:16 2022 X-Original-To: freebsd-stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5A99A198C003 for ; Mon, 31 Jan 2022 02:17:02 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from smtp8.server.rpi.edu (smtp8.server.rpi.edu [128.113.1.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp8.server.rpi.edu", Issuer "smtp8.server.rpi.edu" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JnBXF3yPpz4m71 for ; Mon, 31 Jan 2022 02:17:01 +0000 (UTC) (envelope-from drosih@rpi.edu) Received: from mail-auth4.server.rpi.edu (mail-auth4.server.rpi.edu [128.113.1.234]) by smtp8.server.rpi.edu (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 20V2Gsfl076953 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 30 Jan 2022 21:16:55 -0500 Received: from mail-auth4.server.rpi.edu (localhost [127.0.0.1]) by mail-auth4.server.rpi.edu (Postfix) with ESMTP id CF09758047; Sun, 30 Jan 2022 21:16:54 -0500 (EST) Received: from [128.113.125.57] (calyx-57.net.rpi.edu [128.113.125.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: drosih) by mail-auth4.server.rpi.edu (Postfix) with ESMTPSA id 97D5A58034; Sun, 30 Jan 2022 21:16:54 -0500 (EST) From: "Garance A Drosehn" To: freebsd-stable@freebsd.org Subject: SSHD, diffie-hellman-group1-sha1 , and FreeBSD 13-stable Date: Sun, 30 Jan 2022 21:13:16 -0500 X-Mailer: MailMate (1.13.2r5673) Message-ID: List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_89668C7E-BD76-4B3F-8189-3AB56BE0D23F_=" X-Virus-Scanned: ClamAV using ClamSMTP X-Bayes-Prob: 0.0001 (Score 0, tokens from: outgoing, @@RPTN) X-Spam-Score: 0.00 () [Hold at 10.10] HTML_MESSAGE:0.001 X-CanIt-Incident-Id: 096NegTra X-CanIt-Geo: ip=128.113.125.57; country=US; region=New York; city=Troy; latitude=42.7841; longitude=-73.6756; http://maps.google.com/maps?q=42.7841,-73.6756&z=6 X-CanItPRO-Stream: outgoing X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.113.1.208 X-Rspamd-Queue-Id: 4JnBXF3yPpz4m71 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=rpi.edu; spf=pass (mx1.freebsd.org: domain of drosih@rpi.edu designates 128.113.1.208 as permitted sender) smtp.mailfrom=drosih@rpi.edu X-Spamd-Result: default: False [0.19 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:128.113.1.208]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-stable@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.99)[0.992]; DMARC_POLICY_ALLOW(-0.50)[rpi.edu,none]; NEURAL_SPAM_LONG(1.00)[1.000]; MLMMJ_DEST(0.00)[freebsd-stable]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:91, ipnet:128.113.0.0/16, country:US]; RCVD_TLS_LAST(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --=_MailMate_89668C7E-BD76-4B3F-8189-3AB56BE0D23F_= Content-Type: text/plain; format=flowed; markup=markdown I recently built a new server running freebsd-13-stable, and ran into an unexpected problem. It may be that there is no reasonable fix for this problem, but I thought I'd ask in case I'm missing something simple. This new server is replacing an older server which was last updated in February 2021. The original server needs to accept ssh connections coming some servers which are painfully ancient. Years ago OpenSSH disabled support for the key-exchange algorithm named diffie-hellman-group1-sha1 in the default configuration. Unfortunately my server needs to accept connections from systems so old that they don't support any of the newer Kex algorithms. In my older build of this server, I handled this need by adding the line: KexAlgorithms +diffie-hellman-group1-sha1 in /etc/ssh/sshd_config, and that worked fine. In the newer system that config line flags an error: -# /usr/sbin/sshd -f /etc/ssh/sshd_config4 -t /etc/ssh/sshd_config4: line 156: Bad configuration option: KexAlgorithm /etc/ssh/sshd_config4: terminating, 1 bad configuration options (It's "sshd_config4" instead of "sshd_config" because I have this in a copy of 'sshd' running on a separate port from the standard 'sshd'. This allows me to strictly limit which hosts are allowed to even try to use diffie-hellman-group1-sha1). So far I'm not even sure which component is rejecting the option. I notice, for instance, that the option is still available and works when specified on an 'ssh' command. This command works fine: -# ssh -4e none -oKexAlgorithms=+diffie-hellman-group1-sha1 \ -oCiphers=aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc \ me@sad.ancient.server.rpi.edu (that command will succeed at logging into the ancient server, while 'ssh' cannot login to the ancient server unless I add those two -Options). Based on some searches of the web and mailing lists, I tried an experiment of adding the line: WITH_OPENSSL_KTLS=yes to the file /etc/src.conf . I then did a 'make cleanworld ; make buildworld'. The build and install worked fine, but sshd still won't accept the option for kex diffie-hellman-group1-sha1. Perhaps I have the wrong name for that build-option, or I set it to the wrong value? Or is there some option that I have to specify in the kernel-config file? It will be okay with me if this was an explicit decision to remove all support for the option in favor of better security, but I'm not finding anything to suggest that this change was intentional. I can't even tell when it happened, except to say that it was sometime between Feb 2021 and this past weekend. It might even be that this is a side-effect of building a new system from scratch? My older server was originally built as freebsd-9-stable, and had been upgraded many times until it got to 13-stable. Who knows what cruft is lurking around on it! In any case, if there is some easy way for me to enable the option for incoming 'sshd' connections, that would be very nice. -- Garance Alistair Drosehn = drosih@rpi.edu Lead Developer @rpi and gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA --=_MailMate_89668C7E-BD76-4B3F-8189-3AB56BE0D23F_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I recently built a new server running freebsd-13-stable, = and ran into an unexpected problem. It may be that there is no reasonabl= e fix for this problem, but I thought I'd ask in case I'm missing somethi= ng simple.

This new server is replacing an older server which was la= st updated in February 2021. The original server needs to accept ssh con= nections coming some servers which are painfully ancient. Years ago Open= SSH disabled support for the key-exchange algorithm named diffie-hellman-= group1-sha1 in the default configuration. Unfortunately my server needs = to accept connections from systems so old that they don't support any of = the newer Kex algorithms. In my older build of this server, I handled th= is need by adding the line:
KexAlgorithms +diffie-hellman-group1-sha1
in /etc/ssh/sshd_config, and that worked fine.

In the newer system that config line flags an error:

-# /usr/sbin/sshd -f /etc/ssh/sshd_config4 -t
/etc/ssh/sshd_config4: line 156: Bad configuration option: KexAlgorith= m
/etc/ssh/sshd_config4: terminating, 1 bad configuration options

(It's "sshd_config4" instead of "sshd_config" because I h= ave this in a copy of 'sshd' running on a separate port from the standard= 'sshd'. This allows me to strictly limit which hosts are allowed to eve= n try to use diffie-hellman-group1-sha1).

So far I'm not even sure which component is rejecting the= option. I notice, for instance, that the option is still available and = works when specified on an 'ssh' command. This command works fine:

-# ssh -4e none -oKexAlgorithms=3D+diffie-hellman-group1-= sha1 \
-oCiphers=3Daes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cb= c \
me@sad.ancient= =2Eserver.rpi.edu

(that command will succeed at logging into the ancient se= rver, while 'ssh' cannot login to the ancient server unless I add those t= wo -Options).

Based on some searches of the web and mailing lists, I tr= ied an experiment of adding the line:
WITH_OPENSSL_KTLS=3Dyes
to the file /etc/src.conf . I then did a 'make cleanworld ; make buildwo= rld'. The build and install worked fine, but sshd still won't accept the= option for kex diffie-hellman-group1-sha1. Perhaps I have the wrong nam= e for that build-option, or I set it to the wrong value? Or is there som= e option that I have to specify in the kernel-config file?

It will be okay with me if this was an explicit decision = to remove all support for the option in favor of better security, but I'm= not finding anything to suggest that this change was intentional. I can= 't even tell when it happened, except to say that it was sometime between= Feb 2021 and this past weekend. It might even be that this is a side-ef= fect of building a new system from scratch? My older server was original= ly built as freebsd-9-stable, and had been upgraded many times until it g= ot to 13-stable. Who knows what cruft is lurking around on it!

In any case, if there is some easy way for me to enable t= he option for incoming 'sshd' connections, that would be very nice.

-- =
Garance Alistair Drosehn = =3D drosih@rpi.edu
Lead Developer @rpi = and gad@FreeBSD.org
Rensselaer Polytechnic Institut= e; Troy, NY; USA
--=_MailMate_89668C7E-BD76-4B3F-8189-3AB56BE0D23F_=--