SSHD illegal users
 

Got this in logwatch:
Anything to be worried about?
I have code in my iptables that limits SSH logins to 8 per minute.
)

In computing something is on or it is off, a condition exists or it doesn't, there's no need for fuzzy human "worrying". If you would say "what is the risk?" then I'd say it depends on you implementing the measures I already offered.


8 p/m is way too lenient IMHO, I'd go for 2.

should you worry? yes and no.
these are just attempts to get in....but then no one is ever successful without first attempting ;)

set the AllowUsers keyword.
run sshd on a port different then 22.
allow root login - turn off
use dsa keys
turn off password auth
so many things you can do to lock it down properly..
but it looks like someone has already advised you of all these?

But for AllowUsers, I'd have t allow root wouldn't I or I couldn't do many of the changes I need to on the server?

Is the SSH listening port in SSH config file?

what are dsa keys and password auth?

Why not ssh in as an unprivileged user, then su - to root?Have you looked?

You do not have to allow root to log in to allow a user to su to root. Disallowing root login makes someone log in as themselves and then become root, which creates an entry in the log files.

ssh port is in the sshd config file.

Disallowing password auth means that the user must log in from a trusted account/machine. They won't need a password, but it will be from a account/machine that you know should only have allowed access, because the user has to have a pre-shared key.

DSA and RSA are the two keys usable in ssh. DSA is generally more secure, last I knew.

Please take a look at the sshd config file to get a better idea of your options.

Another thing to read on: http://www.fail2ban.org/wiki/index.php/Main_Page

Brilliant, I've know locked myself out of the server by changing the port and even though I added a firewall rule something has messed.
Argh :(

Right I got it back using KVM.
Now when I edit the SSH port, do you just put in:
Port 1234
for example?

My kiptables rules were changed to:


EDIT: oops, I was chaging the ssh config file not the sshd config file :(

You do not have to allow root to log in to allow a user to su to root. Disallowing root login makes someone log in as themselves and then become root, which creates an entry in the log files.
If I create a new user, what permissions do you give them?
To then login as root is it just su root?
So effectively you have a user login and password and then a 2nd root and password?

ssh port is in the sshd config file.

Disallowing password auth means that the user must log in from a trusted account/machine. They won't need a password, but it will be from a account/machine that you know should only have allowed access, because the user has to have a pre-shared key.
Can't do this as the IP address on my computer is dynamic or am I missing something here? Is a key used instead of the password? Effectively the same process then isn't it?

DSA and RSA are the two keys usable in ssh. DSA is generally more secure, last I knew.

Please take a look at the sshd config file to get a better idea of your options.

i would only ever recommend playing with this stuff locally unless you have another way in.

all the directives you need are in sshd_config

man sshd_config.

it is always good that you have some kind of test server to test out how this all works for you before putting it out live on a production server.

I created a user testuser with password
then added AllowUsers testuser in the config file
However, whenever I login with this user it says access denied after the password.

?

I think I am comfortable having a root password of 20 chars & numbers and resrtricting logins to 2 per min.
any hacker attempting to get through that would have to try for years :)
...and changing the port

Or be extremely lucky :-)

Please use [quote][/quote] tags around the parts of text you are quoting, otherwise it's hard to tell what's your response and what's the original text you're responding to.No special permissions needed. Just an ordinary, bog standard user with a real log in shell (not /bin/false, for example).
Even better, so that you inherit root's environment settings too (see man su).Yes.It's not the machine's IP address that's used to identify the machine, it's the key-pair that are used.Yes, a key's used. The difference is, the key's tied to the machine, whereas the password can roam independent of the machine, which allows anyone to have a go at guessing the right combination of username and password. At least, that's my understanding of it.

You can try sshing in with maximum verbosity turned on to see why it fails:

A difference between a key and a password is that the user never gets a login/password prompt. The key is stored in a file which the ssh client knows where to get it. The key itself is a VERY long string of characters (a couple hundred I think). I think you can do preshared keys even if the client is DHCP, but someone else might know better about that.

On the point of locking out root login. On a Linux machine, root is the only user that is pretty much certain to exist. So, if root isn't available to a hacker, they have to guess both login and password.

(personal opinion follows)
All of it comes down to is which things you find useful in securing the system. Locking out root and alternate ports are the ones I find most useful.

me too.
i use a jumpbox. ssh requests can ONLY come from this box. you get to this box using RSA keyfob, so no password guessing here :)

from the jumpbox, ssh to any servers
no root logins allowed.
sudo access
preshared dsa keys

I disable root login, use passwordless login and use the allowusers directive to limit users.

Passwordless login uses a keypair. One key (the public key if I'm not mistaken) resides on the server; the other one (the private key) is on the the client machine(s) or you can carry it around on a memory stick. The private key is protected with a passphrase. An attacker needs both the private key and the passphrase to be able to get in.

PS I'm not that convinced of moving the port. A port scan will still reveal it as an open port. But that is my opinion and I might miss something.

point blank. but to be honest i never had any problems after moving the port. I guess it's them script kidies that do most of the probing. So moving the port is jut 90% safe. The skilled ones do it the other way anyways. Beside snort most of the time catches those port scans.

To be fool proof. Try something like portknocking to open up the SSH port.