RHEL 7 (CentOS 7) security / ssh / sshd_config advise requested

Question

I am not a sysadmin and try to create a more or less secure web server (LAMP based CentOS 7).
I read several tutorials about setup an initial CentOS 7 droplet and got everything running fine.

However, I am struggling in understanding some basic concepts I read in the articles I read and need some input of more qualified people simply as I am unsure about side affects.

Your input is much appreciated.

Scenario:
I am using cloud-init (User Data) on Digital Ocean to create & provision a new droplet. As far I understand, cloud-init runs as system/root, creating the below settings, in specific for ssh_config for root:

• to create a new user (lets call him admin for this scenario) in line with a ssh key for that user (ssh-authorized-keys)a
• adding that user to groups wheel and set sudo: ['ALL=(ALL) NOPASSWD:ALL']
• disable root login in /etc/ssh/sshd_config
• AllowUsers admin in /etc/ssh/sshd_config
• set PasswordAuthentication no in/etc/ssh/sshd_config
• set PubkeyAuthentication yes & RSAAuthentication yes in /etc/ssh/sshd_config
• configuring firewalld and performing some other tasks

Questions:

1. After connecting my droplet through ssh as user admin the related sshd_config is empty. I assume this is due to the fact that cloud-init runs as system/root when the droplet is created and cloudconfig runs.

   1.1 Do I need to set the same settings here as I did upon droplet creation for the root user? 1.2 If so, what is the sense of multiple ssh_config files?

2. Looking at the cloud-init log file I found a public/private rss key pair for root was created.
   The related password is mailed to me as I decided not to provide an initial ssh key for the root user instead (just for testing purposes).
   However, running ls -a on /etc/ssh of the newly created user admin shows:

   . moduli sshd_config ssh_host_dsa_key.pub ssh_host_ecdsa_key.pub ssh_host_rsa_key.pub .. ssh_config ssh_host_dsa_key ssh_host_ecdsa_key ssh_host_rsa_key

   Looking at ssh_host_rsa_key for example it contains the same ssh key that has been created for the root user.

   2.1 Why and for what purpose that the newly created user I called admin (not root) holds the same keys as root in his ssh folder?

   2.2 Is that because I added him to the groups wheel and sudo: ['ALL=(ALL) NOPASSWD:ALL‘]? Is that recommended?

   2.3 What is the sense of disallowing root to remote login through ssh if another users account can get compromised and also holds all keys needed make a hacker a very lucky person? Is the purpose just to have a user who´s name is more hard to guess?

3. I understood that some actions still require sudo / root privileges. If logged in as admin I can change to root using su root.

   3.1 As I disabled root login in /etc/ssh/sshd_config (that is for ssh only, right?) but the new user created (admin) has the same rights and can easily switch to root I am asking myself what can be done to secure that password better or if there is something such as Two Factor Auth that would add a level of security?

   3.2. On the other hand I don’t understand how that can be a better level of security if a hacker that successfully gained control over the admin account could easily read the ssh keys for root (see previous topic above) and bypass any security layer?

In short: I liked a lot what I was reading, but looking into the filesyste, in specific, after finding the root ssh keys (private & public) in the users ssh folder I created using cloud-init, I am a bit concerned I misunderstood something.

By the way: This is my cloud-init script:

#cloud-config

# log all cloud-init process output (info & errors) to a logfile
output: {all: ">> /var/log/cloud-init-output.log"}

# final_message written to log when cloud-init processes are finished
final_message: "System boot (via cloud-init) is COMPLETE, after $UPTIME seconds. Finished at $TIMESTAMP"

package_upgrade: true

users:
  - name: admin
    groups: wheel
    sudo: ['ALL=(ALL) NOPASSWD:ALL']
    shell: /bin/bash
    ssh-authorized-keys:
      - ssh-dss AAAABBBBBCCCCDDDD...
runcmd:
  - sed -i -e 's/#Protocol 2/Protocol 2/g' /etc/ssh/sshd_config
  - sed -i -e 's/#LoginGraceTime 2m/LoginGraceTime 2m/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PermitRootLogin yes/PermitRootLogin no/g' /etc/ssh/sshd_config
  - sed -i -e 's/PasswordAuthentication yes/PasswordAuthentication no/g' /etc/ssh/sshd_config
  - sed -i -e 's/#RSAAuthentication yes/RSAAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e 's/#PubkeyAuthentication yes/PubkeyAuthentication yes/g' /etc/ssh/sshd_config
  - sed -i -e '$aAllowUsers admin' /etc/ssh/sshd_config
  - service sshd restart

  #firewall
  - systemctl start firewalld
  - firewall-cmd --permanent --add-service=ssh
  - firewall-cmd --reload
  - systemctl enable firewalld

Answer 1

Not an answer to most of your questions, but too long for a comment:

1. the reason for having a separate user (be it "admin" or whatever else) is exactly to put one more layer of authentication/authorization (log in as user with a key/password and then enter another password to become root) into the picture. Unless the user has the same UID as root, it does not have the same rights as root, although it may have bigger privileges than "regular" user.

   It also allows one to give access to the same account to different users - one account can be authenticated via different keys. This makes things easier when you have multiple users (and multiple machines) - revoking permissions for one particular user without interrupting others is just a question of removing one entry from the AuthorizedKeys file (usually ~/.ssh/authorized_keys`. (The same obviously holds for direct root access, but without the additional authentication/authorization level.)

   As for the availability of the keys to the attacker: only the public parts of the keys are (suhold be) kept on the server. During the authentication phase, the client uses his private key, but doesn't leave it anywhere on the server. Thus whoever gains root privileges on the server still doesn't obtain the capability of logging in remotely as a regular user (that doesn't keep his private keys on said machine).

   For other things the usual holds:
   Q: "How do you call somebody who gains root privileges on your system?"
   A: "Yes, sir."

2. Allowing any user to run any commands with root privileges by just prepending "sudo" to the command line is utter misuse of sudo. While some people think it is a great idea, security-wise it is one of the stupidest things to do, since it actually makes everybody a system administrator. The only advantage is that one doesn't accidentally run rm -Rf / with elevated privileges (as one would do by logging in as root directly). But then the muscle memory takes over and people just start using sudo everywhere and the only advantage left is that the commands can be logged. It also defeats the purpose of secondary accounts, as you correctly noticed.

   In short: ALL=(ALL) NOPASSWD:ALL is a Bad Idea^TM, doubly so on a server. Please, don't do that.

   Once you get rid of that, suddenly part 1) starts to make more sense.

Answer 2

CentOS 7 Security Hardening Document that I've just posted might help you out, it's based on OpenSCAP.