Date: Wed, 4 Jan 2017 06:05:54 +0100 From: Polytropon <freebsd@edvax.de> To: Ernie Luzar <luzar722@gmail.com> 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: <20170104060554.36ff4457.freebsd@edvax.de> In-Reply-To: <586C7446.208@gmail.com> 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> <586C7446.208@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 04 Jan 2017 12:04:22 +0800, Ernie Luzar wrote: > Polytropon wrote: > > 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. It's usually limited to dedicated attacks, not those that common script kiddies perform "en masse". :-) > > 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. Yes, firewall rule changing is one option. Another one might be to start and stop the SSH daemon. > > 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. A far simpler solution is to perform the "become root" command as the first action of that user. This can even be automated using ~/.login. A command like "su -l root" or "sudo su -l root" will be executed automatically and _might_ prompt for an additional root password, depending on configuration. > 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? That block needs to be at the end of the sshd_config file. You could also use an "implicit end statement" like this: Match Address x.x.x.x/32 PermitRootLogin yes Match all Otherwise, sshd will complain at startup, and there won't be a SSH service listening on the otherwise enabled port. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170104060554.36ff4457.freebsd>