From owner-freebsd-security@freebsd.org Wed Aug 5 22:26:41 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 318469B350B for ; Wed, 5 Aug 2015 22:26:41 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 274891A59; Wed, 5 Aug 2015 22:26:41 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id 2653B1423; Wed, 5 Aug 2015 22:26:41 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-15:18.bsdpatch Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20150805222641.2653B1423@freefall.freebsd.org> Date: Wed, 5 Aug 2015 22:26:41 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:26:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-15:18.bsdpatch Security Advisory The FreeBSD Project Topic: shell injection vulnerability in patch(1) Category: contrib Module: patch Announced: 2015-08-05 Credits: Martin Natano Affects: FreeBSD 10.x. Corrected: 2015-08-05 22:05:02 UTC (stable/10, 10.2-PRERELEASE) 2015-08-05 22:05:02 UTC (stable/10, 10.2-BETA2-p3) 2015-08-05 22:05:12 UTC (releng/10.2, 10.2-RC1-p2) 2015-08-05 22:05:12 UTC (releng/10.2, 10.2-RC2-p1) 2015-08-05 22:05:18 UTC (releng/10.1, 10.1-RELEASE-p17) CVE Name: CVE-2015-1418 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The patch(1) utility takes a patch file produced by the diff(1) program and apply the differences to an original file, producing a patched version. The patch(1) utility supports patches that uses ed(1) script format, as required by the POSIX.1-2008 standard. ed(1) is a line-oriented text editor. II. Problem Description Due to insufficient sanitization of the input patch stream, it is possible for a patch file to cause patch(1) to pass certain ed(1) scripts to the ed(1) editor, which would run commands. III. Impact This issue could be exploited to execute arbitrary commands as the user invoking patch(1) against a specically crafted patch file, which could be leveraged to obtain elevated privileges. IV. Workaround No workaround is available, but systems where a privileged user does not make use of patches without proper validation are not affected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. A reboot is not required after updating. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install A reboot is not required after updating. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/SA-15:18/bsdpatch.patch # fetch https://security.FreeBSD.org/patches/SA-15:18/bsdpatch.patch.asc # gpg --verify bsdpatch.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile the operating system using buildworld and installworld as described in . VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r286348 releng/10.1/ r286351 releng/10.2/ r286350 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.6 (FreeBSD) iQIcBAEBCgAGBQJVwoplAAoJEO1n7NZdz2rn8D4QAM0077U1nLiJFIU1VcM9IOKp GeZ/w9SnkrKqKzAQpq3QS1hmw0TxvP8kuJNuRVFF6M15Woprfxccb8mDxM0ntru4 t8rq/QLO2jMWopf67Spv6jr6GLLQXkiyRwLEyr7L8a7MbrFwjO1wYt+8GnQ6Nsvn kNfCnbNKPr1gNYM1XsLS7Ej1kl7aBx3xGQXU4d9HlOs/1X7rnPCnGKuc3ZD2Z/N4 zu8pV4NMFhWyJsax+FVYEFxwyd2uEb73A35nz/sQhGiwGOCtL424KG+hwj9mnm45 8f4m+53b6RDcBh6xU41fghMsac2PVCzY2r9GXXXJNlfEa+KnSN8yC+CvtXYEM9BX 9Y5g6i++RVLLT7mwFdG86FjZxSGpDBXlkpZ4I9qiS4YC8MFO4qC7SFzufxtfOcg+ R+QSj+DWOfeHDcXjEkHGlqTW9poE2EDWXDLwlEoOykh9NLyWl6enYd8ZEI3GUqyJ FgKiICrs1vUuGhOhTCgjyQjQUc6jaV/GzhLBJfyxz5xYDpr7DIILxJ8uki2FJcHS tZhlNu6JNqpBlsWNspqjw7NSP2j58Uj0bBdwWvFNX8otQiIXVfkdY8RCjxstq5lT 3bcF6akAFEBx/f/VYM1lswLM/XdbORYC3asLu84BP541EDqdx9d88TeTKNPvyb4Q sGJ763WSlsoLrQDr8CUt =iR0L -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Wed Aug 5 22:26:47 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94C6D9B356B for ; Wed, 5 Aug 2015 22:26:47 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 86D151B0E; Wed, 5 Aug 2015 22:26:47 +0000 (UTC) (envelope-from security-advisories@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1035) id 8647F14AA; Wed, 5 Aug 2015 22:26:47 +0000 (UTC) From: FreeBSD Security Advisories To: FreeBSD Security Advisories Subject: FreeBSD Security Advisory FreeBSD-SA-15:19.routed Reply-To: freebsd-security@freebsd.org Precedence: bulk Message-Id: <20150805222647.8647F14AA@freefall.freebsd.org> Date: Wed, 5 Aug 2015 22:26:47 +0000 (UTC) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 22:26:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-SA-15:19.routed Security Advisory The FreeBSD Project Topic: routed(8) remote denial of service vulnerability Category: core Module: routed Announced: 2015-08-05 Credits: Hiroki Sato Affects: All supported versions of FreeBSD. Corrected: 2015-08-05 22:05:02 UTC (stable/10, 10.2-PRERELEASE) 2015-08-05 22:05:02 UTC (stable/10, 10.2-BETA2-p3) 2015-08-05 22:05:12 UTC (releng/10.2, 10.2-RC1-p2) 2015-08-05 22:05:12 UTC (releng/10.2, 10.2-RC2-p1) 2015-08-05 22:05:18 UTC (releng/10.1, 10.1-RELEASE-p17) 2015-08-05 22:05:07 UTC (stable/9, 9.3-STABLE) 2015-08-05 22:05:24 UTC (releng/9.3, 9.3-RELEASE-p22) CVE Name: CVE-2015-5674 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background The routing information protocol (RIP) is an older routing protocol which, while not as capable as more recent protocols such as OSPF and BGP, is sometimes preferred for its simplicity and therefore still used as an interior gateway protocol on smaller networks. Routers in a RIP network periodically broadcast their routing table on all enabled interfaces. Neighboring routers and hosts receive these broadcasts and update their routing tables accordingly. The routed(8) daemon is a RIP implementation for FreeBSD. The rtquery(8) utility can be used to send a RIP query to a router and display the result without updating the routing table. II. Problem Description The input path in routed(8) will accept queries from any source and attempt to answer them. However, the output path assumes that the destination address for the response is on a directly connected network. III. Impact Upon receipt of a query from a source which is not on a directly connected network, routed(8) will trigger an assertion and terminate. The affected system's routing table will no longer be updated. If the affected system is a router, its routes will eventually expire from other routers' routing tables, and its networks will no longer be reachable unless they are also connected to another router. IV. Workaround Note that this problem does not affect a system on which routed(8) is not enabled. The routed(8) daemon is not enabled by default. Use a packet filter such as pf(4) or ipfw(4) to block incoming UDP packets with destination port 520 that did not originate on the same subnet as the destination address. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. The routed service has to be restarted after the update. A reboot is recommended but not required. 2) To update your vulnerable system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install The routed service has to be restarted after the update. A reboot is recommended but not required. 3) To update your vulnerable system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-15:19/routed.patch # fetch http://security.FreeBSD.org/patches/SA-15:19/routed.patch.asc # gpg --verify routed.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/routed.patch c) Recompile routed. Execute the following commands as root: # cd /usr/src/sbin/routed # make && make install Restart the routed daemon, or reboot the system. To restart the affected service after updating the system, either reboot the system or execute the following command as root: # service routed restart VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/9/ r286349 releng/9.3/ r286352 stable/10/ r286348 releng/10.1/ r286351 releng/10.2/ r286350 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this advisory is available at -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.6 (FreeBSD) iQIcBAEBCgAGBQJVwoplAAoJEO1n7NZdz2rnMFAP/3HWG6FrFxM3jgMcK7a5+nKP O6BqVXpFdia0UUN5JlcEZXc89957mXdMXCDqNeTj3CeDc0p9GbPX1zV/vlYoOqhM eIPwgERbMRFnDRaWm2ClG+aatJvdpeDEioNy8b8tmKq94JcpXIJnwX8dhY3WrMwj Mc3QBGT08XLImHqNw6d6/0wavFeOZ/3g1ZoloAktsgA9KhTUOai6dUhIbIJzk6gh 0oa4NRkhzRNmUKyHOS6HDrghhQ/kZGtE8joVBxLBljK0Thi0mIZtn3UFGsNAgAWw 7WGAiTN2o8c48IUJosmiGsJ7rV1wCFt5zXrZVCcnq6dr60He16Z2Zwif2tugiTvm 5x9lDbTEnYOTxM38Ya5gMtMf733YgAtoRCkf3ROsnwXukJYVsJXms7Ej4NihoKMd aYOLDItl+AXUGIyQ44GuUm2955wo9Fb5RlkDSCLAvdgnkPk+k0puLp0MR0B2MOAI tdKNecRNg0fDR5gJbfdzdjVhsGBZXdYlxo4VjXUXDSZJ+8+jkAg2LA9DTRKIfbgX BX5GiOhkhIivFlgvSePv0LRuIbgt0H1cxiJdk6OqNS5gROuqwo7wwUnaig8KVKOI 887gfpf7PepYD4xWTo3nAoEcGM0rBwUyq1X3pbx9OJADcqRvOhxfMcHFcCv75uxa OISkQhkWdZUv6ls76rRu =p5Rl -----END PGP SIGNATURE----- From owner-freebsd-security@freebsd.org Fri Aug 7 17:46:45 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 67FE09B554A; Fri, 7 Aug 2015 17:46:45 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from cargobay.net (cargobay.net [198.178.123.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4A721A7B; Fri, 7 Aug 2015 17:46:44 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from [192.168.0.2] (cblmdm72-240-160-19.buckeyecom.net [72.240.160.19]) by cargobay.net (Postfix) with ESMTPSA id 77123FA4; Fri, 7 Aug 2015 17:45:42 +0000 (UTC) From: "Chad J. Milios" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: [PATCH] Please review this rc.d/sshd tiny yet ripe low hanging fruit for me. Message-Id: Date: Fri, 7 Aug 2015 13:46:35 -0400 To: freebsd-rc@freebsd.org, freebsd-security@freebsd.org, freebsd-doc@freebsd.org, freebsd-questions@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 17:46:45 -0000 it=E2=80=99s no cannon but i did find a foot-aimed .22 in rc.d/ssh i = think deserves some red paint right away. and while in the neighborhood = i=E2=80=99d like to share an improvement i=E2=80=99ve enjoyed for a = while. i apologize for the list-bombing, if i may have a moment of your = time: TLDR: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D159642&action=3Ddiff= Quick Background: there=E2=80=99s two unrelated issues going on here but i ran across them = in close physical, mental and temporal proximity so let=E2=80=99s just = knock them out together because the solutions are simple, small, and = don=E2=80=99t modify today's default behavior. My Concerns: ONE is adding functionality allowing an admin to tweak the key = generation sshd makes upon its first run using variables in rc.conf = instead of the current day requirement of essentially manually = generating those keys, hopefully the same way, putting them hopefully in = the right place. (not hard for most of us, i know.) TWO, then, is adding = some sort of red paint to a foot-aimed gun i came across when = considering the variable names in rc.d/sshd and lack of mention in = defaults/rc.conf or man 5 rc.conf. My Plea: please put this into head and 10/stable and please 10.2-RC as well. i = know it=E2=80=99s really late for that but seriously if anyone can find = anything wrong with this i=E2=80=99ll send them $10 now just for chiming = in or $20 now for improving/fixing it. hopefully you=E2=80=99ll agree = it=E2=80=99s pretty simple and solid as-is and you'll participate and = say so for the warm feeling. :) Full Story: i=E2=80=99ve been running the following tweak to my /etc/rc.d/sshd for = four years on dozens of machines and apparently applying it on most = installations i do, 10 seconds of my time per, has thus far been less = pain than writing this PR and email, LOL (most times i don=E2=80=99t = even copy it from anywhere besides my temporal lobe, it=E2=80=99s such a = tiny mod): --- /usr/src/etc/rc.d/sshd 2014-11-15 00:04:00.000000000 +0000 +++ /etc/rc.d/sshd 2015-07-14 23:24:11.426005726 +0000 @@ -56,8 +56,9 @@ if [ -f "${keyfile}" ] ; then info "$ALG host key exists." else + eval keygen_flags=3D\$sshd_${alg}_flags echo "Generating $ALG host key." - /usr/bin/ssh-keygen -q -t $alg -f "$keyfile" -N "" + /usr/bin/ssh-keygen -q -t $alg -f "$keyfile" = $keygen_flags -N "" /usr/bin/ssh-keygen -l -f "$keyfile.pub" fi } and then that lets me add this to rc.conf.local, for which i hope my = purpose is apparent and goes without saying: sshd_rsa_flags=3D"-b 4096" sshd_ecdsa_flags=3D"-b 521=E2=80=9D and thanks to already existing functionality i also use the following in = rc.conf.local in every single installation as well: sshd_rsa1_enable=3D"NO" sshd_dsa_enable=3D"NO" so that=E2=80=99s it! that=E2=80=99s my whole functionality improvement = i want included upstream, LOL. However, it rubs me as not adequate, not = ready for general consumption. There=E2=80=99s something wrong and i = couldn=E2=80=99t quite put my finger on it until lately. Been doing that patch for years and never thought much of it. Always was = aware i needed to precede sshd=E2=80=99s first-run with these settings = and didn=E2=80=99t give it a second thought after including it in our = in-house rollout scripts as well as many one-offs for family/friends. = Then, a tech friend/partner/client picked up on those lines disabling = rsa1 and dsa with a little bit of monkey-see-monkey-do but never said = anything to me about it before applying just those on his 9.3 servers = with the stock rc.d/sshd. So i happen to be poking around his hobby rig = the other day and i saw the two *_enable=3D"NO" lines in his = rc.conf.local BUT all five few-month-old keys nonetheless sitting there = in his /etc/sshd/ (!) and, of course, sshd was dutifully responding to = hails on the frequencies he intended to have banned. So he clearly was tripped up on some surprising disappointment of his = expectation that sshd_dsa_enable=3DNO might do as named, as i see = quickly skimming the top of rc.d/ssh might lead one to believe, so, i = propose changing it to sshd_dsa_keygen_enable, if that name even helps = at all, and, more importantly, explaining a bit in the defaults list and = rc.conf(5) that: to effectively change any of these [now] ten settings = one must then also go delete key files that may already exist. I don=E2=80= =99t even know if i=E2=80=99ve accomplished a sufficient explanation in = defaults/rc.conf and wonder if someone familiar with man pages might = improve upon my terse lines in defaults/rc.conf with detail into = rc.conf(5) for us, just documenting sshd_*_keygen_enable and = sshd_*_keygen_flags to make it very clear they are put into effect at a = particular moment in time and to effect a change one must manually = invoke conditions leading again to that particular circumstance (delete = the key so it can regenerate). I know that might seem obvious to most here but it=E2=80=99s not = currently intuitive to those learning. This guy=E2=80=99s a bright = protege and i had to feel bad after i thwacked him in the head with my = bo-staff for having his RSA1 and DSA zippers open because the more i = thought about it the more i realized that as it sits it=E2=80=99s sort = of counter-intuitive. Conclusion: so i=E2=80=99ve improved that years-old tiny patch with slightly better = variable names for the existing vars, plus my own added vars renamed to = follow form, as well as added hopefully meaningful if terse description = to defaults/rc.conf while mapping the old existing names in rc.d/sshd to = the better names along with issuing a warning about them if they=E2=80=99r= e set. any of those decisions/details are optional, i just want the = original functionality of my original tiny patch (aforementioned, = inlined) in head at least, if not my full patch (link, top of message) = into 10.2-RC asap. Thanks everyone so much for your efforts on FreeBSD and hopefully I = haven=E2=80=99t taken up too much of your time pontificating on the = color of the little shed for my poodle=E2=80=99s mini-tricycle and we = can quickly agree this is a good morsel of low hanging fruit to improve = the security, consistency and usability of FreeBSD at the same time and = fast-track it into 10.2, if i=E2=80=99m not being too arrogant and bold = in proposing so. -Chad J. Milios= From owner-freebsd-security@freebsd.org Sat Aug 8 04:05:42 2015 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF2A9B5C4C; Sat, 8 Aug 2015 04:05:42 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from cargobay.net (cargobay.net [198.178.123.147]) by mx1.freebsd.org (Postfix) with ESMTP id 80A951FE6; Sat, 8 Aug 2015 04:05:41 +0000 (UTC) (envelope-from milios@ccsys.com) Received: from [192.168.0.2] (cblmdm72-240-160-19.buckeyecom.net [72.240.160.19]) by cargobay.net (Postfix) with ESMTPSA id 69415FE5; Sat, 8 Aug 2015 04:04:43 +0000 (UTC) From: "Chad J. Milios" Message-Id: <218890C8-9306-4CAF-9AEF-35664275B340@ccsys.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Subject: Re: [PATCH] Please review this rc.d/sshd tiny yet ripe low hanging fruit for me. Date: Sat, 8 Aug 2015 00:05:37 -0400 References: To: freebsd-rc@freebsd.org, freebsd-security@freebsd.org, freebsd-questions@freebsd.org In-Reply-To: X-Mailer: Apple Mail (2.2102) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 04:05:42 -0000 On Aug 7, 2015, at 1:46 PM, Chad J. Milios wrote: > ...i apologize for the list-bombing, if i may have a moment of your = time: > TLDR: > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D159642&action=3Ddi= ff > =E2=80=A6.. > My Concerns: > ONE is adding functionality allowing an admin to tweak the key = generation sshd makes upon its first run using variables in rc.conf = instead of the current day requirement of essentially manually = generating those keys, hopefully the same way, putting them hopefully in = the right place. (not hard for most of us, i know.) TWO, then, is adding = some sort of red paint to a foot-aimed gun i came across when = considering the variable names in rc.d/sshd and lack of mention in = defaults/rc.conf or man 5 rc.conf. > =E2=80=A6.. FYI, I have ported the identical functionality now to the = security/openssl-portable and security/openssl-portable-devel ports so = no one has to miss out. Please would you try one out and now configure = your (-b)etter keys in a consistent way in new deployments from now on = or upgrade yours if you are using defaults and delete existing = /etc/ssh/ssh_host_foo_key* files manually if you intend to update them. Knocking out little fixes like this will keep making things like sysrc = more useful and mergemaster even more worthless, bless its tired heart. = Help assure this works as intended in many cases with as many ssh = options as possible. THANKS PATCHES: either... base system: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D159642&action=3Ddiff= = ports/security/openssl-portable https://bz-attachments.freebsd.org/attachment.cgi?id=3D159654 = ports/security/openssl-portable-devel https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D159655&action=3Ddiff= = Thank you all. PS here are a couple configs I=E2=80=99d like to hear = everyones thoughts on. Let=E2=80=99s mix up the monoculture more: openssh_rsa1_keygen_enable=3D"NO" openssh_dsa_keygen_enable=3D"NO" openssh_rsa_keygen_flags=3D"-b 4096" openssh_ecdsa_keygen_flags=3D"-b 521" openssh_ed25519_keygen_enable=3D"YES" #default sshd_rsa1_keygen_enable=3D"NO" sshd_dsa_keygen_enable=3D"NO" sshd_rsa_keygen_flags=3D"-b 16384" sshd_ecdsa_keygen_enable=3D"NO" sshd_ed25519_keygen_enable=3D"NO" openssh_rsa1_keygen_enable=3D"NO" openssh_dsa_keygen_enable=3D"NO" openssh_rsa_keygen_enable=3D"NO" openssh_ecdsa_keygen_enable=3D"NO" openssh_ed25519_keygen_enable=3D"YES" #default Can we have a conversation about how best to configure things to require = && (and) keys instead of || (or) keys for certain/all users? Using = sshd_config and/or PAM? openssh_rsa1_keygen_flags=3D"-b 16384=E2=80=9D openssh_dsa_keygen_enable=3D"YES" #default openssh_rsa_keygen_flags=3D"-b 16384" openssh_ecdsa_keygen_flags=3D"-b 521" openssh_ed25519_keygen_enable=3D"YES" #default