Only permit certain IP's to login as root through ssh
 

I have a linux server at the office that I occasionally need access to from home, so I have the router (Netgear RangeMax NEXT Wireless-N WRN8348 v2) forwarding the port for access. Typically, when I'm logging in to the machine, I need root access, but I don't want to permit everyone in the world to try to crack the root account.

Is there any way that I can have it so that only IP addresses from the LAN can log in as root through ssh, and everyone going through the router has to use a different account to log in before issuing a "su -"? I'm getting tired of having to issue the command so often.

you want to do all that becuase you're "tired" of typing in 4 characters?? blimey. root should *never* be allowed to log in through SSH, end of story. What you're currently doing is technically correct. the best kind of correct.

There's no way to match up IP and user, but if you really want something like this, just use something like fail2ban to block all IP's who try to log in as root with the wrong password, probably the best way if you really have to.

Enter the beloved pam_access(8) facility. (What distro are you using?)

On RH-family distros, you'd simply add to your /etc/security/access.conf:
(where 10.0.0.0/24 is your home subnet)

---

Or... in sshd_config you could use the AllowUsers directive, e.g.:
(where 10.0.0.* represents your subnet wildcard, and bert, ernie, and natasha are legitimate users you want to be able to ssh in)

And there are plenty of times where root needs to login via ssh...

...such as your job forces you to use a vulnerability tool that has to login via root through ssh. Oh and by the way it only runs from windows. Oh and by the way, you can't set the encryption type. So you are stuck with AES. So for instance if you get a Solaris 10 box which is setup to use 3DES and you can't change it, you can't scan the box...

Sry, more of a rant.

no, well ranted in general, I knew access.conf could do that... so why didn't I remember? I've even implemented this in the last year. How embarrassing. I didn't know you could put IP's in allowusers though. Horrible thing to put into sshd_config though, seems totally the wrong place for it IMHO.

I still do not agree with the root access thing, there are better ways to do this, like sudo once logged in as a normal user. The simpler and cleaner the security model the better. Don't let root log in on ssh ever.

well you can't be using 10/24 as a remote subnet. This would be your public IP address from over the internetland. Relevant for internal routing though, but not over the net.

I arbitrarily made up his local network as 10/24; I added the LOCAL directive as well so that he wouldn't lock root out of non-network ttys and cronjobs. ;)

I completely agree.


Especially since anyone replying should have noted the OP trying this for all the wrong reasons there is no necessity to come up with exotic scenarios for justifying root login exceptions or ranting. What I mean is that lots of users do not understand SSH the way they should so we should point them to sane security defaults and not confuse them with exceptions or maybe's. Anyone not able to adhere to standards or best practices for compatibility reasons knows what to do already anyway. No need to promote that.

First off, it isn't exotic at all. It's what we're forced to do everyday when securing boxes, however those boxes aren't put on the network until they are fully secured.

Secondly, I'm not going to sit there and tell someone there is never a reason to allow root to login via SSH. I'd say sure you can, but you really don't want to...

For normal administration, yes absolutely login via a normal user and use sudo. Which most people don't know how to use properly anyway and allow shell escapes so once someone does sudo su - you loose all of your loggin capability.

Anywho this isn't ment to turn into a thread war I just don't like telling people you should never do something when there are legitamate reasons.

Also, there are a lot of cool things you can do with allowing root logins via SSH:

PermitRootLogin with-out-password
PermitRootLogin forced-commands-only

used in a lot of remote automated tasks. Use the above with appropriate firewall restrictions and/or tcpwrappers and you can allow root login via ssh pretty securely.

nomb

You're arguing, which is completely unnecessary if you read (and understood) my reply well.

IMO, there is NO reason to log into a machine as root. People who do are almost always following a path of least resistance or are ignorant of the security impact of doing such. To suggest such undermines the efforts of many to establish best practices. Besides, that is what sudo is for, no? And some distros won't even allow you to log in as root. You're saying your thoughts on this are much better than collective wisdom, based on some scenario that you've experienced which is more than likely not a generalistic scenario (or at least' it doesn't sound like it...never experienced such requirements myself).

At the risk of dragging this out indefinitely, I think it's important to draw the line between:

1. "Hi, I'm an idiot and I want to allow root logins for bad_reason_here."
2. "Hi, I've got a use case that legitimately requires direct root logins from foo network."

Scenario #1 presents itself the vast majority of the time, so it's easy to be skeptical on this topic. But in the rare cases that #2 legitimately occurs, it is nice to know how to configure things safely.

Whether you agree with any of this digs down into fundamental opinions on sshd usage.

Thanks for the information on how to do this. :)

I'm using Ubuntu Server 9.04, which is a rather minimal setup without a GUI or hi-resolution console, and this is category 1, "Hi, I'm an idiot and I want to allow root logins for bad_reason_here." I think I'm also using a distro that "won't even allow you to log in as root," but their restrictions on a root login only slowed me down for about 12 seconds. If anyone is curious, my bad reason is that I'm lazy, and it's aggravating to do this 30 times a day.

I'll spare everyone most of the drama, but I'm quite overworked and overburdened at the moment because of various hardware, software and network problems, most of which aren't my fault (the rest are normal software development bugs). :banghead: Things that were priority 1 urgent a month ago are being lumped in the category of, "I MAY start on that next week." Things that were less severely urgent 9 months ago are in the category of, "I wonder if I'll ever start on that," and there is no one to help at our tiny company.

At this point, the pleasantry of a more welcoming ssh login is worth the extra security risk that someone may get into our LAN and then find the machine to crack ssh access into as root. It's a bigger concern that I won't be able to keep up with everything or that I'll suffer a breakdown. I'm sure there are much more interesting things to do once you're on our LAN anyway, like steal free access to commit internet crimes. There is only one other person in the company who even knows how to use ssh. He avoids using it whenever he can, is quite busy with other work, and wouldn't even know how to mess up the system.

Someday, I'll come back and secure things more, but I have about 800 hrs of work to push through first (assuming I write bug-free code, nothing ever breaks, and no customer ever needs anything from me), which was all urgent at one point. Sometimes, security mainly secures you from getting as much done.

You can also configure ACL's by port using the RFX networks apf firewall.

How about using the tcp wrapper. It is supported by all the distro that I am aware of. Just need to add something like this in your /etc/hosts.deny & /etc/hosts.allow

A very hardening approach would be :

Where you are not allowing anyone to access any service to your server except 192.168.67.0/255.255.255.0 and 193.78.135.208/255.255.255.240 network.

Another approach would be :

Here we are allowing ssh access only from the above subnets. We can even put comma separated host ips instead of the subnets.