What you have done is atypical and so I would not recommended it. Most programs assume a one to one mapping between uid and username. You could potentially open yourself to weird bugs/unknown behaviour or worst security vulnerabilities - This is an unknown for me so I cannot recommend it when there are better/more typical ways to achieve your goals. Given this, the first thing I would do is delete the accounts you have created.
Now, if the users require root access there is nothing majorly wrong with giving them access to the root account, assuming you/they understand the risks associated with the root account. From a security perspective the weakest point in ssh is password auth, so I highly recommend disabling that. This can be done by editing/adding the following to
However, there are some issues with having root privileges for longer than you require. Most notably that it is easier for a simple mistake to do more damage. Given this it is better to create some unprivileged accounts that the users can login to. Once logged into their user that can obtain root privileges when required by using
su - and the root password.
Now, remote attacks are generally against the root users (as well as common users names such as
admin), with password auth disabled you generally do not have to worry about this as key auth is strong enough. If you have user accounts that can obtain root privileges (as described above and below) then you can further increase security by disabling the root account entirely by add/editing the following to
WARNING: Ensure you have a user account that can gain root privileges or you can lock yourself out of the server.
This might help protect you against misconfiguration or possible future vulnerabilities against ssh/openssl as the attacker now also requires a username to gain access to an unprivileged account where they then require a password to gain full root access.
Finally, it is not best practice to share password around multiple users. If you wish to revoke someone access for any reason everyone needs to learn a new password. It is better to obtain root privileges using the user's own password. This way you simply need to lock the user's account, change the root password (as they could have modified it given they have root privileges) and everyone can continue to use their own passwords without issue (note there are more issues with locking someone out of a server they have had root access to as they could have done anything to the system, including changing other users passwords or adding their key to other users).
To do that you can use
sudo in place of
su to allow the users to obtain root privileges with their own password as aspose to roots. To do this install
sudo and add the user to the
sudo group (depends on the distro you use). Users can then use
sudo <command> to run a command with root privileges or
sudo -i to gain a root shell.
This also gives you better auditing logs as each action executed by sudo is logged against a username - assuming you do not simply
sudo -i all the time.
You can even take this further by restricting users to running only a subset of commands rather than giving them access to everything. This makes it easier to revoke access in the future as they are able to do less to the system. But this depends on how much you trust your users and can be annoying if you do not know everything they require access to.
Given this an attacker requires a username as well as an ssh key or a vulnerability in key based auth to gain access to the server, where they can do limited damage. Then they require a password to actually gain root privileges and do real damage.
Security is applied in layers, the more layers you have generally the more secure you are. But added layers also decrease usability. It is up to you to decided the balance you wish to apply to a given system. The steps I have described above will add allot of security at a minimal cost to usability. There are further steps you can take to lock down systems even more than this but for most cases this should be enough.