logon to server with regular account and bad password 12345678
sudo su-
12345678 and you have a root shell..

Surely to step up to the root user from a regular account you should be issuing a separate password. I see the thought behind protecting the root password by never having to type it and no one having to know it, but with sudo su – someone can gain root without the root pw anyway, so whats the point of protecting it if its not needed anyway.

Just my 2 cents anyway..

VPN would be fine but it is very slow compared to SSH. No, this is *not* due to protocol (I’ve timed VPN and SSH and there is no detectable difference in throughput). It is instead due to the edge firewalls that trap / track all VPN traffic and the shitty VPN clients the organization wants us to use.

To sum up: keep your SSH server clean of all other software, use local low-priv user accounts, use only PK for authentication, maybe tie in IP filtering to prevent hackers from even knowing about your listening port. Port knocking is too complicated for me to explain to users, or I’d be using that instead (tres kewl approach).

thank you

This tutorial very useful as the sysadmin.

# Turn on reverse name checking
VerifyReverseMapping yes

Don’t do this. It will cause you a painful delay when logging in, should your DNS servers get inaccessible (i.e. uplink down) or misconfigured.
Exacty the moment you need to fix it ASAP.

And, probably, a lot of “POSSIBLE BREAK-IN ATTEMPT” useless chatter in your syslog should your ssh clients’ reverse zone be misconfigured somehow (a lot of ISPs are misconfigured that way, so nobody cares). Don’t know if recent versions of sshd do that, though. Seen that on older systems.

Basically everybody implicitly agrees that the fundamental security model of Unix/Linux is flawed in at least these ways:
- It doesn’t scale well ( more than 1 admin *have* to use one account: root)
- It doesn’t offer sufficient granularity ( you either have all with root, or almost nothing)
- It is virtually impossible to guarantee accountability in all cases.

I would be interested to see developments to solve that problem in more fundamental way than to patch it up with nice or, more often, ugly and cumbersome add-ons.

~/.ssh/authorized_key or ~/.ssh/authorized_key2

here is the place where you past the new key.

ssh only knows the key if you are using one and all that proves is that the person had access to the key. Using a key for root is fine but you would still need to set a password for root (in case the network is down and you have to access the server from the console). With remote root login enabled, I would only need access to someone else’s PC and the password for root. There is nothing that could be used, forensically, on the server to identify me. At least if I had to log on to my own, personal, account and then su to root the IP address AND the originators login are recorded.

Having said that, though, if you haven’t got centralised logging once you’ve got access to root you just delete the auditing files and do whatever it was you weren’t supposed to be doing!!!

Frankly, someone being rude in such a way is only going to make that person look less intelligible and that person will also be taken less seriously. It comes down to constructive criticism versus being arrogant and holding little argument, in the end.

And the funny thing is, regarding his remark of you might as well turn off ssh. Well then why not go further and say: turn off the computer? Ah right – because any computer is not 100% secure, even a computer that is off. Yes, you should secure it as much as possible but to claim turning off ssh is going to make it magically more secure is ridiculous. In that case, you may as well turn off other services that are far less secure. Indeed – there’s many attack vectors out there, and as you (Philippe) point out not having a valid login is pretty much not nice for an attacker if you can’t login with root remotely. Indeed, by the time you may find a valid login, you may have been blocked by a firewall or some other system. Exactly why the old apache phf bug was so useful: it wasn’t so you could crack root password, it was so you could get a valid login so you can get one step closer and you could even have possibility of trying a local exploit – more of those than remote, more than likely. If you by chance had a root password found, fine, but that wasn’t the only use of it (clearly).

Thing is – the original person, anomie, was correct.

> “you might as well turn off ssh because you are clueless and incompetent.”

No need to be rude to enlight your point.
Insults are inappropriate in a technical debate, and counter-productive.

A brute force attack is much more difficult if you don’t now any login.

Why ? Try it yourself: when you try a login + password, system rejects you but never says what was wrong : login or login+password

Mathematically, you’ll have to multiply number of average attempt for root login by number of possible login name, which makes a real difference, and give system more opportunity to reject your IP and stop your attack.

strong passwords: agreed, I don’t think the root password should be shared – hence the fair enough remark. Still though, one less password can be a flaw. It isn’t necessarily a flaw, but it can be. See next point (i already mentioned this one though but will again).

sudo su: true, however, as you point out it is useful at times (I used this one a lot in the past and still do at times). But still, my point of getting a user password (keeping in mind some don’t have nearly as strong passwords as they should) and then having sudo access could be a problem IF that password is stolen. The problem isn’t even really the set up in a lot of the cases, but that the user is who chooses the password and the password is one of the weakest links in the chain of security. Because lets face it: if you can make it, you can break it.

I’ll give you that sudo has some benefits, e.g, not having to have a root password set or even not having it known to more than one, but there’s still some issues with it. That’s all I was getting at. I think what it boils down to is actually it depends on the environment, the amount of users, etc. Or even limiting root to one user (be it by groups, or changing user requirements, whatever the case may be. I mean a programmer doesn’t need root, necessarily). Obviously with multiple administrators you do have an issue right from the get go. Best solution may not be a solution at all in some cases: again, environment and requirements is a part of it.

As for my remark about security being complete. Yes, agreed you shouldn’t dismiss it. That would be a terrible mistake (as has been proven time and again especially lately). It actually bothers me in many ways – security is the responsibility of everyone working together (there goes the passwords being weak or written down issue again).

Anyway, I’ll finish by saying: yes, it has its uses. But at same time, just like chroot has potential issues, so to does sudo. Then again, what doesn’t ? My main points were simply you should always log off and keep your passwords safe – else you run into trouble. And of course, nowadays a real issue is more web related. The amount of non filtered queries to databases, etc., is a real hazard to a lot of people!

# strong passwords: An admin knowing the (shared) root password needs also to memorize a personal password for doing things that do not require root access. With sudo, the admin has one password less to worry about, which leaves more energy and motivation for a single, stronger, password.

#sudo su: this is circumventing the use of sudo. Still you need to use one password less than with not using sudo. Also, sudo su has its uses. Sometimes I create a user account that is locked, e.g., no password exist to login. But with sudo su you can still login.

Yes, complete security will never be achieved, but I believe sudo is a step in that direction.