From owner-freebsd-questions@freebsd.org Wed Jan 4 04:04:17 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 AD407C9E656 for ; Wed, 4 Jan 2017 04:04:17 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E4151D16 for ; Wed, 4 Jan 2017 04:04:17 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-pf0-x242.google.com with SMTP id y68so26423791pfb.1 for ; Tue, 03 Jan 2017 20:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=jLSZynEZY0FAtHy4PpE6Tx9hA74ghqztawdFAWrG6+A=; b=Srn4UP/BlQIa+u/SFsGDE5fMlF2LYclbk62VgQcU8sUYVsHRdNre3DPR1ELmS4Az5Z 3zkPvOgrQakwkZZIh4+YgeugFxVAY60MyeqhRF5WeeyWn5/SEGk3tk2EucXqKfhtIbtT KKBpNyBrHi3FGENqz+fCdx6PUBaygAEZ7lDlbORIhoJXipR8YC9szvRkdY+s6OrmO8FJ 4p55eNIUlqxLPKpByeiIC7xGP1J8vtf+9rpPgJnez5NQqJf0H79Xn6Xu+HiRdIx3uBgq SlAf0SJRBTW4ELWS6vGZNhDqfK7JzexryifES81MVTmW0iuxLwHKGcnZmOASeoWHPYih +VzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=jLSZynEZY0FAtHy4PpE6Tx9hA74ghqztawdFAWrG6+A=; b=BG9b1o8n+0+parK/prIJXwQQul1jCgTgkR5j7tBXf1Mj69V4ikW8UbKjPcWZGhgXqr WJP725s6ec1/oNyYJscEQP9H3dsT3OWFsQzJl5zoVgeuhvI0KYZ8NFlnpJbEG1QNf8bg x7CYspqDu48Y/e073YIr8T4a+sxxeTvIFiEvY4dGlSQSO6r74ctMv7qEZoKZ8lO8aEto htLA6JtArNSFeSbszJl4FnE2WqOG6xaq7KyEONVbQ1BqymATs/vf9T/xjL5IHMUnno4n gJZjABDVJ7/X44c7RoNkrSCyUQlimAjH2l9gIi3SYyRuN4aslunWIZ/pXjll43h2uU78 a2OA== X-Gm-Message-State: AIkVDXI087OqNvmgjKbwhu9xgeR9DpQV3Yw+ju+8ecwHiBlcYYBcKep2gwZzQPYmfeIvWA== X-Received: by 10.84.208.227 with SMTP id c32mr141646312plj.144.1483502656856; Tue, 03 Jan 2017 20:04:16 -0800 (PST) Received: from [192.168.1.103] ([120.29.76.197]) by smtp.googlemail.com with ESMTPSA id i124sm144715126pgd.15.2017.01.03.20.04.15 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Jan 2017 20:04:16 -0800 (PST) Message-ID: <586C7446.208@gmail.com> Date: Wed, 04 Jan 2017 12:04:22 +0800 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Polytropon CC: "freebsd-questions@freebsd.org" , Maciej Suszko Subject: Re: how to allow user toor login through ssh 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> <20170104024723.af718b7a.freebsd@edvax.de> In-Reply-To: <20170104024723.af718b7a.freebsd@edvax.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 04:04:17 -0000 Polytropon wrote: > 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. In 15 years of using a high value port number for remote ssh access and never having a single login attempt is what I call security. Now in most cases portmap just checks a small number of known port numbers. To run portmap on the complete range of possible port numbers takes a long time and to do that while rolling through a range of ip address may take many days that is why it just not done. > > 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. yea I played with it before. If I remember correctly it adds and removes firewall rules on the fly. I don't want my firewall played with. > > 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). I have a user like this. The problem is created files or directories are owned by this user. Only way to get ownership of root is to be logged in as root or toor or use the chown command. > > > I added this to /etc/ssh/sshd_config Match Address x.x.x.x/32 PermitRootLogin yes x.x.x.x being the ip address of the pc I use from home to login. This locked me out all together. The /var/log/auth.log file shows this error message Directive 'Subsystem' is not allowed within a Match block What is it complaining about?