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:
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?
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, runningls -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?
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