Tips on Hardening Centos7?

[virtualmin2019]

So I'm browsing on the net and there's like 50 different steps to hardenning. I'm not sure which is true and which isn't.

Does anyone have any guideline for what is the fundemental security settings to prevent problems in the future?

The only one I know so far is change ssh port from 22 to something else. The rest is a complete question mark.

Are these two enough?

https://wiki.centos.org/HowTos/Network/SecuringSSH

https://wiki.centos.org/HowTos/OS_Protection

[lightman47]

I'm no expert - but I change my ssh ports every so often - when Fail2ban starts showing numerous ssh attempts. It doesn't take long for 'them' to find the new port. Then I change it again. You can keep an eye on /var/log/secure to see the attempts.

Do NOT allow root logins from outside. Period. You can also use certificates I believe, to avoid the passwords altogether. Ssh in as a normal user, then su, if you must once connected.
Do NOT run as root - especially if you're going to be connecting to anything on the web while you are! Instead, run as a normal user and invoke sudo (or su -) for only the tasks requiring root access. (You'd be surprized at how quickly you adjust to this! Make up your mind and stick to it).
Install Fail2ban
Make sure firewall and Selinux are running and enabled.

- just off the top -

[virtualmin2019]

I'm no expert - but I change my ssh ports every so often - when Fail2ban starts showing numerous ssh attempts. It doesn't take long for 'them' to find the new port. Then I change it again. You can keep an eye on /var/log/secure to see the attempts.

Do NOT allow root logins from outside. Period. You can also use certificates I believe, to avoid the passwords altogether. Ssh in as a normal user, then su, if you must once connected.
Do NOT run as root - especially if you're going to be connecting to anything on the web while you are! Instead, run as a normal user and invoke sudo (or su -) for only the tasks requiring root access. (You'd be surprized at how quickly you adjust to this! Make up your mind and stick to it).
Install Fail2ban
Make sure firewall and Selinux are running and enabled.

- just off the top -

thx for replying I'm trying to learn so much stuff hehe.

Quick question when you disable root login, does this make the current username we have to access the vps via gitbash or any other command prompt like puTTy useless?

Also when you enable private key for authentication, how does it recognize your logging from that location? Does it automatically create a key in your local computer and use that to login? I currently have the same thing I think(there's like a code generated into my computer during my first time login as root, when I deleted the server it became obsulete so I had to delete the old one and make a new one) but I still need to login using root ip and password.

What do you think of BIOS and Disk Partition settings? Are they necessary for security as well?

[lightman47]

root login for ssh comes disabled by default. I recommend NOT enabling it.
You never mentioned those 'requirements' in your original post - ("I'm no expert"}. However, if you have created a 'username' (not root) there shouldn't be an issue.

Also when you enable private key for authentication, how does it recognize your logging from that location?

Again - the "I'm no expert". I don't believe location matters but rather the contents of the private key. Others here are experts - I offered generic help to your generic request.

[TrevorH]

root login for ssh comes disabled by default. I recommend NOT enabling it.

No, it doesn't. Out of the box both CentOS 6 and 7 open port 22 in the firewall and openssh is set up to allow anyone to login, including root.

[TrevorH]

when you enable private key for authentication, how does it recognize your logging from that location?

When you generate an ssh key using ssh-keygen, it makes two files. One contains the private key, the other the public key. The private key should have a passphrase added to it to stop it from being used if ever the file is stolen. The public key contains nothing secure so can safely be shared around. When you come to use the key, you connect to ssh and provide the username you want to login as - the ssh server will then check in that user's home directory for their allowed ssh keys - it checks $USER/.ssh/authorized_keys by default although that name and location can be changed (though it's best not to). So you provide the username, the ssh server takes that username and uses it to locate the public key. The client encrypts the data using the private key and the server decrypts it using the public key. If they don't match the it won't decrypt and the connection is disallowed.

You must install the public key in the user's $home/.ssh/authorized_keys file. The permissions on both /home, /home/user, /home/user/.ssh and all the files in that .ssh directory must be exact and set to be what openssh demands they be or the login will be rejected. The files must be owned by the user in question and there must be no group write allowed.

[lightman47]

Then what is the point of this (commented out) in /etc/ssh/sshd_config?
#PermitRootLogin yes

I've obviously incorrectly assumed the default was NO and I'd need to un-comment it to enable root login. Additionally, (perhaps for another reason) /var/log/secure rejects attempts 'user < 1000'. What am I missing?

[TrevorH]

All the commented values in /etc/ssh/sshd_config are the ones that are set by default if they are not specified. You only need to uncomment them if you want to change to something non-default.

[lightman47]

ok - but that was my point - you un-comment the entry to ALLOW root logins ? Or are you telling me it's YES by default?

{We were both responding while I tried to 'clean-up, reorganize my reply - apologies}

[lightman47]

Hang on - experimenting with logins I've never tested because of my (now proven false) assumptions!
Grr.