Date: Wed, 04 Jan 2017 12:04:22 +0800 From: Ernie Luzar <luzar722@gmail.com> To: Polytropon <freebsd@edvax.de> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org>, Maciej Suszko <maciej@suszko.eu> Subject: Re: how to allow user toor login through ssh Message-ID: <586C7446.208@gmail.com> In-Reply-To: <20170104024723.af718b7a.freebsd@edvax.de> References: <5869ADFB.6080000@gmail.com> <20170102024359.aa82ae3e.freebsd@edvax.de> <5869F77D.5050106@gmail.com> <20170102172615.516dc912.freebsd@edvax.de> <CAOc73CCc_Yj_qAw2riDft=KdeNoKmHgOQOkeTLdse2pom_35FQ@mail.gmail.com> <20170103141838.4ada403b@helium> <586C4D68.6000000@gmail.com> <20170104024723.af718b7a.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <woodsb02@gmail.com> 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?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?586C7446.208>