From owner-freebsd-questions@freebsd.org Wed Jan 4 01:47:30 2017 Return-Path: Delivered-To: freebsd-questions@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 5816BC9C609 for ; Wed, 4 Jan 2017 01:47:30 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mailrelay15.qsc.de (mailrelay15.qsc.de [212.99.187.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.antispameurope.com", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BEE201C71 for ; Wed, 4 Jan 2017 01:47:29 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mx01.qsc.de ([213.148.129.14]) by mailrelay15.qsc.de; Wed, 04 Jan 2017 02:48:35 +0100 Received: from r56.edvax.de (port-92-195-83-137.dynamic.qsc.de [92.195.83.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPS id 3DBFE3CC3F; Wed, 4 Jan 2017 02:47:24 +0100 (CET) Received: from r56.edvax.de (localhost [127.0.0.1]) by r56.edvax.de (8.14.5/8.14.5) with SMTP id v041lN9x001995; Wed, 4 Jan 2017 02:47:23 +0100 (CET) (envelope-from freebsd@edvax.de) Date: Wed, 4 Jan 2017 02:47:23 +0100 From: Polytropon To: Ernie Luzar Cc: "freebsd-questions@freebsd.org" Subject: Re: how to allow user toor login through ssh Message-Id: <20170104024723.af718b7a.freebsd@edvax.de> In-Reply-To: <586C4D68.6000000@gmail.com> References: <5869ADFB.6080000@gmail.com> <20170102024359.aa82ae3e.freebsd@edvax.de> <5869F77D.5050106@gmail.com> <20170102172615.516dc912.freebsd@edvax.de> <20170103141838.4ada403b@helium> <586C4D68.6000000@gmail.com> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-cloud-security-sender: freebsd@edvax.de X-cloud-security-recipient: freebsd-questions@freebsd.org X-cloud-security-Virusscan: CLEAN X-cloud-security-disclaimer: This E-Mail was scanned by E-Mailservice on mailrelay15.qsc.de with E609668345D X-cloud-security-connect: mx01.qsc.de[213.148.129.14], TLS=1, IP=213.148.129.14 X-cloud-security: scantime:.2180 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 01:47:30 -0000 On Wed, 04 Jan 2017 09:18:32 +0800, Ernie Luzar wrote: > Maciej Suszko wrote: > > On Tue, 3 Jan 2017 19:15:54 +0800 > > Ben Woods wrote: > > > >> The openssh daemon prevents login as root or toor (any user with UID > >> 0) in the default configuration that ships with FreeBSD. > >> > >> This can be adjusted by setting the following in /etc/ssh/sshd_config: > >> PermitRootLogin yes > >> > >> Note however, that it is not generally advisable to allow root or toor > >> login via ssh, as this is a frequently attempted username for script > >> kiddies and bots running random brute force attacks. Tread wisely. > >> > >> Regards, > >> Ben > > > > However it's quite simple to restrict root login using Match block, for > > example ;-) ... just leave 'no' globally. > > > > Match Address 10.0.0.0/27 > > PermitRootLogin yes > > > > I like this solution. On my host I have changed ssh to us a high value > port number back when I was on BSD REL 3.0 and have never had any failed > login attacks of any kind. Moving SSH to a nonstandard port doesn't increase security per se, but it reduces the "noise" of the log files significantly. Script kiddies who only try on :22 can be dealt with; those who run a portscan prior to the attack (more sophisticated, sometimes non- automatic attacks) will see the new SSH port and try there. An additional idea is to use SSH "port knocking" where the SSH port needs to be enabled by a specific action performed on a different port. The result can be time-controlled, or the port becomes unavailable after logout again. There still is the approach of allowing a non-root SSH login for a user (UID != 0) that is permitted to use su, sudo or super. In this case, the "PermitRootLogin" option can be kept on "no" securely. Of course also make sure that _this_ user account has a strong password (or better, uses keys). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...