I have several systems, mostly running RedHat, on which I need to be able to log in directly as root while still maintaining the greatest possible level of defense against anyone trying to hack in by guessing the password.
I've already limited the IP's that are allowed to connect, but IP's can easily be faked.

Is there a system setting or application that you can use (possibly in conjunction with ssh/scp) that checks not only your IP and password, but uses some additional method to verify that the connecting machine really is what it claims to be?

Thanks!

None really. ssh with good iptable rules is the best way but honestly, the most secure method is to not allow direct root login over a remote session.

I've sometimes used RSH public/private keys on servers that I frequently connect to, and was hoping there would be something out there that used a similar pair of keys to allow the two machines to confirm each other's identities. As far as that goes, that seems like something that could be extremely useful to a lot of people so I'm kinda surprised to find that it hasn't been invented yet.

What do you think? Would an application like I described attract enough users to warrant creating it?
(I'm still at the "figuring out how to get scripts to do what I want" level and don't have the slightest idea what would be involved in actually building an application from scratch.)

Thanks again!

I'm not sure that you have fully taken on board the previous reply. If we take a paranoid approach to security (at least as a thought experiment...and maybe in practice, too, if we can) we would never allow a direct root login to occur remotely. That doesn't mean disallowing a login as another user, who uses 'su' to get to the root. This has the advantages that:

• idiots who are just scripting brute force root login attacks are going to fail
• you can log root login attempts (i.e. su's) by user, making those and perhaps get early warning if anyone is trying an attack

And you need two (rather than one) account/password combinations to get anywhere. And, if the only user who is allowed to su to root has quite a long username (and not just something obvious like !"£$%^&*()slartibartfast1234567890 ) and secure password, that isn't going to happen by chance either.

When you say it sounds as if there may be some specific set of tasks that you intend to perform. If so, have you considered creating a user with just enough permissions to get that list of tasks done? Or a user who can 'sudo' to do them?

Another vague possibility that comes to mind is to allow ssh only by mac address in iptables (rather than by ip address). Now mac's can be faked too, but there are quite a lot of them and the chances of someone hitting on the right mac by accident seem quite low. It is a bit 'security by obscurity', but it seems to me that this would mainly be vulnerable to someone who already knew what they were looking for and had done some packet snooping.

You can use 'authorised keys' in ssh, but you should not allow root remote login. If you ever check your /var/log/messages or equiv, you'll see that automated brute force attempts to login as root are very common these days.

I agree logging in over networks, hostile or not, as root account user is not best practice. Maybe if you can explain what you need to do we can help you find a solution that doesn't involve lowering security but doesn't involve you having to jump over all sorts of hurdles either?

There are several good points (and questions) above. I more or less expected them, especially the admonitions against allowing direct root login. I know it's not the best way to do things, but didn't want to bog down my post with a [very] long-winded explanation of why I'm stuck with doing it that way. There are a lot of different factors involved; bureaucracy, 'grandfathered' procedures that I can't change, outdated or impractical "security requirements" and, most of all, not enough time to do the large-scale rebuilding of the things that should be done differently. Not to sound unappreciative or excessively cryptic, but it all boils down to "this is the way I have to do it".

That's one reason I'm surprised that no one has come up with a way to make direct root logins safe from brute force attacks again. If such a method doesn't exist then I'll do the best I can with ssh, IP limits, and - thanks for the idea salasi - mac addresses in iptables.

Thanks again - even if the answers weren't what I was hoping to hear.

Doug

See the manpages for sshd_config(5). There are some important caveats if you enable this.

Let root log in w/o a password at all? I'll bet there are some caveats! Thanks for the info.

Doug

[EDIT]Setting without-password is a good idea.[/EDIT] If you can establish a SSH session (as unprivileged user) to an access restricted bastion host on the edge of that LAN and then run a SSH tunnel over that connection to a host deep inside the LAN that would not be "better" but functional.

Nope. You're going to have to actually read the manpages this time.

???
How? The only possible way I know is using proxy. But I think you can deny connection from anything excluding the only computer you use to remotely log in.

Well, if you really HAVE TO do it, use authorised keys ie Public/Priv keys instead of password, ideally move sshd to listen on a different port, otherwise it will get swamped (cpu & logfile space) by those automated attacks I mentioned.
Also, as mentioned, try to restrict IP addrs and MAC addresses. Theoretically they can be faked, but that usually means its an inside job ie the attacker knows what the values should be, in which case you've got bigger problems...

good luck

Thanks. I did just that. I'll edit my reply to reflect that.

Yeah, I was cheerfully on my way to read the man pages when I posted that.

The man page didn't go into a lot of detail about the full extent of what PermitRootLogin without-password does, but if I understood the context (and later posts here), it not only means that root can't log in through ssh with it's regular password, but that root can only connect from a machine from which it has a valid RSA public/private key set up in advance.
Is this correct? If so, then I think it's going to be exactly what I'm looking for!