From owner-freebsd-doc@freebsd.org Fri Aug 7 17:46:45 2015 Return-Path: Delivered-To: freebsd-doc@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-doc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Documentation project 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=