From owner-freebsd-security@freebsd.org Sun Sep 12 14:02:56 2021 Return-Path: Delivered-To: freebsd-security@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 13E83666AA4 for ; Sun, 12 Sep 2021 14:02:56 +0000 (UTC) (envelope-from markus.falb@fasel.at) Received: from uruz.anode.at (uruz.anode.at [188.40.148.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H6rsp73CFz4ptH for ; Sun, 12 Sep 2021 14:02:54 +0000 (UTC) (envelope-from markus.falb@fasel.at) Received: from 84-113-78-5.cable.dynamic.surfer.at ([84.113.78.5]:34065 helo=dwalin.fasel.at) by uruz.anode.at with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1mPQ4E-0007yT-RC for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:47 +0200 Received: from winch.fasel.at ([10.10.10.10]:55958) by dwalin.fasel.at with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1mPQ4F-0005Rk-IN for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:47 +0200 Received: from [10.12.10.2] by winch.fasel.at with esmtp (Exim 4.67) (envelope-from ) id 1mPQ4E-0002PR-E0 for freebsd-security@freebsd.org; Sun, 12 Sep 2021 16:02:46 +0200 From: Markus Falb Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: Important note for future FreeBSD base system OpenSSH update Date: Sun, 12 Sep 2021 16:02:42 +0200 References: To: freebsd-security@freebsd.org In-Reply-To: Message-Id: <8169A4A8-B8D1-4265-87C8-74ED4D34FBC8@fasel.at> X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Spam-Score: 0.0 (/) X-Spam-Report: Scored with 0.0 by uruz.anode.at, TVD_RCVD_IP=0.001 X-Rspamd-Queue-Id: 4H6rsp73CFz4ptH X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of markus.falb@fasel.at has no SPF policy when checking 188.40.148.130) smtp.mailfrom=markus.falb@fasel.at X-Spamd-Result: default: False [-1.60 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[fasel.at]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:188.40.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-security]; RECEIVED_SPAMHAUS_PBL(0.00)[84.113.78.5:received] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2021 14:02:56 -0000 > On 09.09.2021, at 20:01, Ed Maste wrote: > > OpenSSH will disable the ssh-rsa signature scheme by default in the > next release. > > ... > > To check whether a server is using the weak ssh-rsa public key > algorithm, for host authentication, try to connect to it after > removing the ssh-rsa algorithm from ssh(1)'s allowed list: > > ssh -oHostKeyAlgorithms=-ssh-rsa user@host FWIW, some of us may already have dealt with that. FIPS enabled RedHat Enterprise Linux (and probably other FIPS enabled systems) means effectively no ssh-rsa signature available in the sshd. I had that situation at the beginning of the year. As mentioned, ssh-rsa signature algorithm will stop working, but that does not automatically imply that every RSA key must be changed to something other. The signature algorithm is not a property that is inherent to the key. That said, existing RSA keys were working fine for me (my openssh client was rsa-sha2-256 and rsa-sha2-512 capable) but when I tested with some popular windows clients (filezilla, putty) it failed (apparently no rsa-sha2 algorithms available). I found it interesting that mentioned clients were ecdsa capable but did not support sha2 signatures with RSA keys. Maybe the situation changed in the meantime to the better. There are 3 scenarios: 1. both sides support rsa-sha2 signatures -> RSA keys still working 2. one side does not support sha2 signatures but does support other key types -> you can change key type 3. one side does not support sha2 and no other key type -> you loose A prominent candidate for 3. would be Cisco IOS Best Regards, Markus