From owner-freebsd-security@freebsd.org Sat Jul 21 22:45:20 2018 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B143B102EDE8 for ; Sat, 21 Jul 2018 22:45:20 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C4457AE4D; Sat, 21 Jul 2018 22:45:19 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.15.2/8.15.2) with ESMTPS id w6LMjC88061220 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 21 Jul 2018 15:45:12 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id w6LMjABf061218; Sat, 21 Jul 2018 15:45:10 -0700 (PDT) (envelope-from jmg) Date: Sat, 21 Jul 2018 15:45:10 -0700 From: John-Mark Gurney To: Dimitry Andric Cc: Grzegorz Junka , freebsd-security@freebsd.org, Chad Jacob Milios , Damien Miller Subject: Re: Possible break-in attempt? Message-ID: <20180721224510.GQ2884@funkthat.com> Mail-Followup-To: Dimitry Andric , Grzegorz Junka , freebsd-security@freebsd.org, Chad Jacob Milios , Damien Miller References: <594ba84b-0691-8471-4bd4-076d0ae3da98@gjunka.com> <368EABCF-A10A-49E9-9473-7753F6BEAA50@patpro.net> <8EDDBDB2-77F5-4CF5-8744-41BEA187C08A@FreeBSD.org> <201807201905.w6KJ59hn079229@donotpassgo.dyslexicfish.net> <2E502F45-E6F6-44D7-AE9E-9B8B08C1CEBE@nuos.org> <0DDFA4FB-4FAB-49F0-99E8-9958DB1D889F@nuos.org> <91123dcd-529a-1c92-16bf-f9060d3f1fa6@gjunka.com> <1EBE0612-CDB0-452D-ABB0-BFF133B1CBE0@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EBE0612-CDB0-452D-ABB0-BFF133B1CBE0@FreeBSD.org> X-Operating-System: FreeBSD 11.0-RELEASE-p7 amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Sat, 21 Jul 2018 15:45:12 -0700 (PDT) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jul 2018 22:45:21 -0000 Dimitry Andric wrote this message on Sat, Jul 21, 2018 at 22:30 +0200: > On 21 Jul 2018, at 21:29, Grzegorz Junka wrote: > > > > On 21/07/2018 12:05, Chad Jacob Milios wrote: > >>> On Jul 21, 2018, at 7:57 AM, Grzegorz Junka wrote: > >>> On 21/07/2018 11:03, Chad Jacob Milios wrote: > >>>>> On Jul 20, 2018, at 3:05 PM, Jamie Landeg-Jones wrote: > ... > >>>> openssh-portable (in ports, produced by the paranoid fellows at OpenBSD) has actually switched to adopt this, UseDNS no, as their default configuration for, i think its been a couple years now. This is in addition to dropping the message from their log output if UseDNS yes. > >>>> > >>>> There is no point to this foolishly alarming message. Be mindful of the OTHER ways you must surely have in place to keep your sshd hard against attack. > >>>> > >>> Good to know. But the documentation says setting to no prevents from using DNS in known_hosts. When I look into my known_hosts I see many dns-only names, e.g. github.com among others. > >>> > >>> GrzegorzJ > >> In which man page or web page are you seeing this information? > > > > > man sshd_config > > > > UseDNS Specifies whether sshd(8) should look up the remote host name, > > and to check that the resolved host name for the remote IP > > address maps back to the very same IP address. > > > > If this option is set to ???no???, then only addresses and not host > > names may be used in ~/.ssh/known_hosts from and sshd_config > > Match Host directives. The default is ???yes???. > > Interestingly, this documentation is an outdated version, and wrong. :) > It was reported upstream: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2554 > > and fixed here: > > https://github.com/openssh/openssh-portable/commit/0235a5fa67fcac51adb564cba69011a535f86f6b > > The documentation is now: > > UseDNS Specifies whether sshd(8) should look up the remote host name, > and to check that the resolved host name for the remote IP > address maps back to the very same IP address. > > If this option is set to no, then only addresses and not host > names may be used in ~/.ssh/authorized_keys from and sshd_config > Match Host directives. The default is "yes". > > E.g., it affects only authorized_keys files, but I'm not sure if there > is such a thing as a "from" directive in those (and neither could I find > any documentation about "from" directives in known_hosts files either). Yes, there is. From ssh_config(5): A pattern-list is a comma-separated list of patterns. Patterns within pattern-lists may be negated by preceding them with an exclamation mark (`!'). For example, to allow a key to be used from anywhere within an organization except from the ``dialup'' pool, the following entry (in authorized_keys) could be used: from="!*.dialup.example.com,*.example.com" and from sshd(8): from="pattern-list" Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in the comma-separated list of patterns. See PATTERNS in ssh_config(5) for more information on patterns. In addition to the wildcard matching that may be applied to hostnames or addresses, a from stanza may match IP addresses using CIDR address/masklen notation. The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key). sshd(8) also has the other restrictions that you can put on keys in the authorized_keys file. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."