Too many authentication failures about hardening

[konstruktoid]

Thanks for the report @pascalandy and sorry for such a late reply, but f_firewall is present as function f_firewall in https://github.com/konstruktoid/hardening/blob/master/scripts/02_ufw. Regarding the naming; functions can't be numbers, since it's not a valid identifier.

Please increase MaxAuthTries (https://github.com/konstruktoid/hardening/blob/master/scripts/18_sshdconfig#L25-L29) and see if the problem persists.

[pascalandy]

Alright, I thought this project was creating a new user somewhere along the line. So all my

Authorized users only. All activity may be monitored and reported.
Received disconnect from 123.123.123.12: 2: Too many authentication failures

maybe due to the fact I was using root :-p Will let you know !

[pascalandy]

Looks like https://github.com/konstruktoid/hardening/blob/master/ubuntu.sh#L24 should call https://github.com/konstruktoid/hardening/blob/master/scripts/02_ufw

Curious to know why the names are different.

[pascalandy]

I'm actually provisioning new machines.
I think you should use branches to develop feature and ensure master is always your golden copy :)

[pascalandy]

Same error.

Authorized users only. All activity may be monitored and reported.
Received disconnect from 123.123.123: 2: Too many authentication failures

I also saw few error when the scripts started:

[12] /etc/hosts.allow and /etc/hosts.deny
[13] /etc/issue
[14] /etc/login.defs
[15] /etc/sysctl.conf
./scripts/13_sysctl: line 12: /sys/module/nf_conntrack/parameters/hashsize: No such file or directory
[1] /etc/security/limits.conf
[2] /etc/adduser.conf and /etc/default/useradd
[3] root access
[4] Installing base packages
./scripts/17_packages: line 4: dmidecode: command not found
./scripts/17_packages: line 8: dmidecode: command not found
Selecting previously unselected package acct.
(Reading database ... 25242 files and directories currently installed.)
Preparing to unpack .../acct_6.5.5-2.1ubuntu1_amd64.deb ...
Unpacking acct (6.5.5-2.1ubuntu1) ...
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for systemd (229-4ubuntu19) ...
Setting up acct (6.5.5-2.1ubuntu1) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults

It's sad as I would love to use your template. I really enjoy the way you organized this project. Keep up the good work.

Cheers!

[konstruktoid]

Hi again @pascalandy, I find it odd you're missing nf_conntrack/parameters/hashsize and dmidecode. Could you provide more details about the machines you are provisioning?

And regarding branches; you're absolutely right, I've just been lazy when it comes to my own repositories. Will start a develop branch right away.

[konstruktoid]

Using the Vagrantfile for testing, I'm not having any issues with nf_conntrack/parameters/hashsize or dmidecode on Xenial, Zesty, Yakkety or Artful.

[pascalandy]

I know there is always little subtle differences between cloud providers that break my scripts. I'm not using Ansible or Terraform at this point.

As I said, I provision bare-metal server on packet.net (type 0). If you want, I would be glad to do a live session with. We we could provision machines on the spot and test till we find the issue.

I use a standard Ubuntu 16.04 fresh install each time. Packet is known to have fresh images.

[konstruktoid]

Adding test if nf_conntrack/parameters/hashsize or dmidecode are missing.
Just to verify, can you check if the nf_conntrack kernel module is loaded?

[konstruktoid]

Tests added and dmidecode replaced with dmesg; e5d51ab

[pascalandy]

Not sure if I should do something here.

[konstruktoid]

Any failures after e5d51ab?
And nf_conntrack/parameters/hashsize is only present if the nf_conntrack module is loaded.

[pascalandy]

OK will try !

[pascalandy]

Same error. Btw I use root to login. Is it ok?

> ➜  _infra git:(2.05) ssh root@$IP_PUBL_NODE_21 -p22;

Authorized users only. All activity may be monitored and reported.

Received disconnect from 123.123.123.12: 2: Too many authentication failures
Disconnected from 123.123.123.12

[konstruktoid]

No, root is not allowed to log in.
https://github.com/konstruktoid/hardening/blob/master/scripts/18_sshdconfig#L11

[pascalandy]

Ok. In this case, which user should I use?

[konstruktoid]

It's all about how you provision your servers, root should never be allowed to login and can be locked (https://github.com/konstruktoid/hardening/blob/master/scripts/36_lockroot), create a user and use sudo to gain superuser privileges instead. If not possible, change PermitRootLogin to yes in the sshd-config file and unlock the root user.

[pascalandy]

in /etc/ssh/sshd_config I changed update PermitRootLogin no to PermitRootLogin yes
and I'm still locked down.

EDIT: I also tried to bypass https://raw.githubusercontent.com/konstruktoid/hardening/master/scripts/36_lockroot

same result.

[konstruktoid]

Does it work if you create a normal user and try to connect?

[pascalandy]

I did start to create a user but then many thing breaks ... At this point I can't confirm.

[konstruktoid]

What did break?

[konstruktoid]

Since the root user shouldn't be allowed to remotely access a system or be used as a normal user, there are multiple configurations that need to be changed, eg:
https://github.com/konstruktoid/hardening/blob/master/scripts/16_rootaccess#L4
https://github.com/konstruktoid/hardening/blob/master/scripts/18_sshdconfig#L11
https://github.com/konstruktoid/hardening/blob/master/scripts/36_lockroot#L4

[pascalandy]

What did break?

Mostly my existing scripts, ssh keys.

[pascalandy]

I see the 3 lines you point out are SEDs.
Should I just delete those lines and root will stays untouched

[konstruktoid]

Without logs it's pretty tricky to pinpoint the exact cause of the failures.
I believe so, but consider not using the root account at all.

[pascalandy]

I'm OK with using root at the moment. Fully aware that I must move on with a new another user in the future.
I'll try #5 (comment)

[konstruktoid]

Closing due to inactivity.

[rams3sh]

I faced a similar issue and I dont login with root but with another custom user using certificate based login.

SSH has a default behaviour of trying through all ssh keys present as part of your default ~/.ssh/ folder before trying the one passed using -i option. This tweet explains the issue and also has a solution which was helpful for me in solving the problem.

Posting it here just in case if it helps anyone else who faces a similar issue as myself in future.

Link: https://twitter.com/podalirius_/status/1422123401855049730

[konstruktoid]

Thanks @rams3sh!
ssh -i ./keys/id_rsa [email protected] -v -o IdentitiesOnly=true is the TL;DR