Skip to main content

Creating New Users

Change current user password, prompt for current passwd - passwd
If you can sudo, run sudo passwd <user> to change a user password without prompt for current password, and with no security restrictions (min length, difficulty, etc)

Run the following commands to create a new user on Linux -

These commands assume you are root, on a new host, so you do not need to prefix them with sudo, if you are not root you will need to run sudo adduser <username>, etc.

adduser username
Adding user `username' ...
Adding new group `username' (1000) ...
Adding new user `username' (1000) with group `username' ...
Creating home directory `/home/username' ...
Copying files from `/etc/skel' ...
New password:
Retype new password:
passwd: password updated successfully
Changing the user information for username
Enter the new value, or press ENTER for the default
        Full Name []: # You can leave all of this blank, or not
        Room Number []:# Your choice, really
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y

# If vim is your preferrred text editor, set the environment variable to say so -
export EDITOR=/bin/vim


sudo visudo
# Both of these commands will do the same thing, since we've set our preferred editor
sudo vim /etc/sudoers
Configure Sudo / Group Access

Find the section within /etc/sudoers called user privilege specification

# User privilege specification
root ALL=(ALL:ALL) ALL

Modify the file by adding the user to the section as it appears below, granting all permissions -

# User privilege specification
root ALL=(ALL:ALL) ALL
username ALL=(ALL:ALL) ALL

Save /etc/sudoers and run vigr in the terminal and add your new username created to the sudo group, and any other groups you may want. This is the same thing as modifying the configuration file /etc/group with your preferred editor and saving it. (Docker is a common group that users will need added to - Don't run your containers as root by running sudo docker)

...
tape:x:26:
sudo:x:27:USERNAME,USERNAME2,USER3
audio:x:29:
docker:x:30:USERNAME,USER3
...

When saving /etc/group, you'll get some output warning you about consistency between a shadow configuration file. Go ahead and edit it to mirror your changes, and ignore the final warning about the /etc/group file consistency since we just came from modifying that file.

vigr
You have modified /etc/group.
You may need to modify /etc/gshadow for consistency.
Please use the command 'vigr -s' to do so.

vigr -s
You have modified /etc/gshadow.
You may need to modify /etc/group for consistency.
Please use the command 'vigr' to do so.
Securing User / Group IDs

You should change your user and group IDs from the default sequential values we can assume Linux has distributed for us. To do this, choose and valid ID and edit the following commands to suit your needs -

# Change user and group IDs
sudo usermod -u 1234 user
sudo groupmod -g 4321 usergroup

# Make sure you edit all the old permissions to reflect the above changes
# Use the old user and group IDs here
sudo find / -group 1000 -exec chgrp -h username {} \;
sudo find / -user 1000 -exec chown -h username {} \;

Not sure what UID and GID to choose? See the table below and choose a value that suits your needs - probably a value within an unused range. UID and GID do not need to be the same - This is only the case by default when adding a user via Linux Distributions such as Ubuntu, which is the one referenced / used in this guide. Feel free to specify unique values, and research more into sharing user groups for permissions in scenarios such as granting a list of employees or developers similar access.

UID/GID Purpose Defined By Listed in
0 root user Linux /etc/passwd + nss-systemd
1 ... 4 System users Distributions /etc/passwd
5 tty group systemd /etc/passwd
6 ... 999 System users Distributions /etc/passwd
1000 ... 60000 Regular users Distributions /etc/passwd + LDAP/NIS/…
60001 ... 61183 Unused    
61184 ... 65519 Dynamic service users systemd nss-systemd
65520 ... 65533 Unused    
65534 nobody user Linux /etc/passwd + nss-systemd
65535 16bit (uid_t) -1 Linux  
65536 ... 524287 Unused    
524288 ... 1879048191 Container UID ranges systemd nss-mymachines
1879048191 ... 2147483647 Unused    
2147483648 ... 4294967294 HIC SVNT LEONES    
4294967295 32bit (uid_t) -1 Linux  
Table Source - Systemd.io

You should validate all the configuration done to secure your server - for example, this could be validated by running the following commands to check UID / GID after setting them and logging into our user.
Check UID / GID
id -u username
id -g username

If you plan to stop here, be sure to login to your new user before making further changes to your system.

sudo su username
# Or
sudo -iu username
Creating SSH Login Keys

If you don't plan to use this user for logging into another host, you shouldn't need to continue with ssh-keygen configuration. Simply add your public key to the authorized hosts file at /home/username/.ssh/authorized_keys so that you will be able to authenticate via SSH using your intended public key.

If you spun up a Droplet with DigitalOcean, they give you the ability to load the server with an approved public key. This means that there will already be an authorized_keys file created for us with the same public key we used to login with our root user. Run the following commands from your user's home directory so you may authenticate with your public key. 

sudo cp -r /root/.ssh .
sudo chown username .ssh/ && sudo chgrp username .ssh/
sudo chown username .ssh/authorized_keys && sudo chgrp username .ssh/authorized_keys

Later, we will disable logging in with the root account - it's important to setup SSH access for other users beforehand!

SSH should never be authenticated using passwords alone, using public keys and ssh-keygen we can authenticate based on a a key we generate and distribute manually. This should be done with care, as a combination of sloppy authorized_keys files and lost / stolen keys can lead to a compromised web server!

sudo su username
cd
ssh-keygen -t ed25519

if you run the above command as sudo, it will create a key for root@host, not the user you are logged in as.
If you are getting privelege errors, you are not in your home directory. Create the key there first, then move it to your preferred location later. (usually /home/user/.ssh/)

general format for filename is user_<keytype> so -> username_ed25519
this will create a public and private key, the private key should(?) be backed up on an encrypted USB drive and removed from the server

Once the files are generated, they sit loose in the users home directory - clean them up

mkdir .ssh
sudo mv username_ed25519* .ssh/

Create an authorized_keys text file within the .ssh/ directory, and paste in the public key from within username_ed25519.pub - this is the file that will be checked for approved keys, the username_ed25519.pub is for your own records. Keep it there, delete it, put it on a usb, back it up.

Do not leave your private key on the server, should someone get this keyfile they can change your password and login as long as that key is on the approved list. These will unauthorized logins / password resets will not be viewed as a breach attempt, but as an approved login - no one will be alerted until its too late.

Using Putty with OpenSSH Keys

At some point when a password is used in key generation, ssh-keygen generates openssh private key which doesn't use cipher supported by puttygen.

ssh-keygen doesn't provide option to specify cipher name to encrypt the resulting openssh private key.

There is a workaround: remove the passphrase from the key before importing into puttygen.

Create a copy of the key to temporarily remove the password
cp ~/.ssh/id_ed25519 ~/.ssh/id_ed25519-for-putty

import the copied key, using the -p argument to specify a request to set a new password, and -f to specify the import keyfile.

ssh-keygen -p -f ~/.ssh/id_ed25519-for-putty
Enter old passphrase: <your passphrase>
Enter new passphrase (empty for no passphrase): <press Enter>
Enter same passphrase again: <press Enter>

using some command, view the text contents of the private key generated.

cat id_ed25519-for-putty
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZWQyNTUxOQ
AAACCGyjniPP1oVCXqkdCeCKFp+5+5cI7L79rP5RYHJ5Y6fQAAAJh3QGp1d0BqdQAAAAtzc2gtZWQy
NTUxOQAAACCGyjniPP1oVCXqkdCeCKFp+5+5cI7L79rP5RYHJ5Y6fQAAAEBJr8PzmuEN6qNyrY07Lr
LAgZRjo9efYETKqFbS2jVTQobKOeI8/WhUJeqR0J4IoWn7n7lwjsvv2s/lFgcnljp9AAAADmthcHBl
ckBrYXB1bnR1AQIDBAUGBw==
-----END OPENSSH PRIVATE KEY-----

copy this output from your ssh session to the machine running Putty

On the windows machine, create a .ssh directory in the users folder who wishes to SSH into the server (C:\Users\Shaun\.ssh)

navigate inside the directory, and create a text file - paste the output from your private key into this file, file->saveAs In the dropdown 'save as file type', select 'All Files', be sure to end the keyfile name with the .key extension -> username_ed25519.key click save.

Open puttygen, load convert->import keys.. select the text file we created in C:\Users\Shaun\.ssh\ and set the passphrase from puttygen.

Don't forget to shred and remove ~/.ssh_id_ed25519-for-putty afterwards since it is not password protected.

The new password protected key will authorize the user based on the local password set in putty, using the remote PUBLIC key stored on the server.

There is no need to keep your private keys on any server, or any device connected to the internet.

 

Back to top