- Executable file wiki_references/2017/software/MaidSafe_net/src_from_GitHub/the_repository_clones/QA/Documentation/Managing Remote Servers.md — part of check-in [0105d215ce] at 2017-03-22 04:01:30 on branch trunk — Massive_Array_of_Internet_Disks Safe MaidSafe + Rust (user: martin_vahi, size: 3423) [annotate] [blame] [check-ins using] [more...]
Managing Remote Servers
The objective of this document is to detail a standard process for handling remote servers (e.g. Droplets), so that all MaidSafe remote servers are secure and can be accessed in a similar way. This should make working with and scripting for these simpler.
Note that this does not apply to "throw-away" remote servers which are used for short-term testing, and need not be secure.
Setting up a New Server
Where there is a choice, we should never allow the host to send us a root password via email. If a root or sudo user's password is ever emailed (even internally between two MaidSafe employees), it should immediately be treated as compromised and changed.
In the case of Droplets, we should add all QA members' SSH keys by default. This allows any QA
member to ssh into the droplet as root. However, this should generally only ever be done once, in
order to create the new
qa user as detailed below. Working as root is not a good practice and
should be kept to a minimum.
As soon as a new server is created, the following steps should be taken:
- ssh into the server as root
create a sudo user named
qawith a strong, unique, random password. On Ubuntu:
adduser qa adduser qa sudo
or on Fedora:
useradd qa passwd qa usermod qa -a -G wheel
exit the ssh session
add details of the server to an existing or new document in the QA folder of the private Assets repository
Managing the Servers
If the password of a sudo user is compromised (e.g. laptop lost/stolen, password emailed), all affected servers should be updated as soon as possible. As passwords should be unique, this should apply to just a single user account on a single server.
The fix can either be to change the password, or to delete the user.
Compromised SSH Key
If the private SSH key of a sudo user is compromised (e.g. laptop lost/stolen, private key emailed!), all affected servers should be updated as soon as possible.
The hard part will be identifying all the accounts to which this key has access. For a QA team member, this will likely include the root user, their own user account and perhaps other users' accounts on every remote server.
The fix is to remove the affected key from the relevant
authorized_keys files. This will be in
Adding new Users
If for whatever reason, a non-QA team member wants to access a remote server, don't share
credentials with that member; instead create a new user account for them. Normally, the only shared
account should be the
qa one (an exception is the
peer1 account on the
Before creating an account for them, ensure that they really need access to the secure server. If their work can be done on a non-secure, throw-away Droplet for example, then that is the best option.
Don't give the new user sudo access if not required. If sudo access is required, then create the new user with a strong, unique, random password, but don't email this password to the team member. Instead, send it via a mumble message.
The team member should be asked to never change the password to a weak one, nor to one which they use elsewhere. They should also notify QA once the account can be deleted.