Wave

Setting up a new Linux Server

Mia Rose Winter

Table of Content


Every goddamn time I create a new VPS or something and install ubuntu I have to google together all the little steps and commands I need to run to give it a baseline of security, I am writing this one down now.

Creating a custom user

Script kiddies love pinging random servers with root and see where they can get in, I once ordered a new server but didn't configure it until the next day, and when I logged in with root it told me there had been 900 logging attempts (over night!). So yea, let's create our own account:

Add a new user

$ sudo useradd -m -G sudo rose

-m is to also create a home directory for that user (we put our ssh key there), -G sudo adds them to the sudoers group

Set up a password:

$ sudo passwd rose

now open another terminal, ssh with that new user into the server and see if you can run commands with sudo ls or something. When you have valiated your newly created user works and can use sudo, you can exit that root-user terminal.

Transfer SSH keys

You always wanna use ssh with your server, because otherwise if someone gets your password they can just login as well, so if you don't have a certificate yet, create one like this:

$ ssh-keygen -t rsa -b 4096

I already have my certificates, so I just hope what I just copied from a website actually works, let me know if it doesn't. And btw, there is apparently a better algorithm than rsa, but 4096 rsa is fine, just don't go below 3k, that's not fine.

Now it comes to uploading this to our server, when you are on linux and have openssh, this is easy.

$ ssh-copy-id rose@<server>

but if you are on windows, things are different, and this one always took me ages to look up, but you can do this (I believe you need powershell, but not sure since I always use that anyway):

$ cat ~/.ssh/id_rsa.pub | ssh rose@<server> "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Secure server

And of course, to round it all down (as we say in Germany), disable root:

$ sudo passwd -l root

And configure ssh by opening

$ sudo nano  /etc/ssh/sshd_config

And add/change/uncomment the following properties:

PermitRootLogin no
PermitEmptyPasswords no
PasswordAuthentication no
MaxAuthTries 6

Note: There is also X11Forwarding, that apparently usually should be disabled, but for me it always made me unable to connect to the server (maybe because I use my domain to connect to the server and not the ip), so I leave it.

apply it by calling

$ sudo systemctl restart sshd

and now open a new terminal window and try logging in with root (it shouldn't work, even with the correct password), and then try logging in with your account (it should work). If not, especially the second one, you have your first terminal window to fix/debug things. If you have closed it, congratulations, you are locked out of your server, install your server anew and start from the beginning, do not take 2.000 USD.

Change the ssh port?

You can of course change the SSH port, this way no automated attack would even hit the right port on your server, but in my personal opinion, root is disabled, what they gonna do anyway.

Overlay VPN

@buzzle@mas.to has raised another point on how you can make your server even more secure.

On 2024-04-18 they wrote:

Here's one extra thing you can add into the server setup guide: if you don't need public access to ssh (99.9% of the time you don't), throw it on an overlay VPN like Tailscale, ZeroTier or DefinedNetwork and then just block up the ssh port completely.
Skids-be-gone.

source

About the Author

Mia Rose Winter

Software Developer / Project Manager. Full-time cat Woman and bisexual menace. Really not liking tech these days, I have more fun writing stories and books. Developer of GeeksList, Just Short It and Wave.

This might also interest you

A Mystery Involving Hardware Security Modules and Value Tokens

Forbidden Tempura 10/7/2025

Context Historical context In July, 2021, the phenomenon known as the &ldquo;Gigaleak&rdquo; continued. The Gigaleak was a drip-feed of part of the ill-gotten data from the 2018 Nintendo data breach. On July 20, 2021, the iqcvs.tar.xz file was uploaded to the now-defunct file sharing website anonfiles.com and thereby made available to the public by The Hacker Known as 4chan. This file contains a dump of CVS repositories. The repository sw contains the BroadOn network infrastructure around the middle of the year 2006. This is shortly before the Nintendo Wii launched. The network infrastructure was initially launched alongside the iQue Player, a variant of the Nintendo 64 featuring downloadable games and some anti-piracy measures of questionable quality (non-HTTPS link) intended for the Chinese market, which was and still is notorious for being particularly prone to piracy. It was developed by a company then called BroadOn Communications Corp., a California corporation. The iQue Player u

ITInfodump

A Brief Look at the 3DS Cartridge Protocol

Forbidden Tempura 6/2/2024

About a week ago, there has been a little addition to the 3dbrew wiki page about 3DS cartridges (carts) that outlines the technical details of how the 3DS cartridge controller and a 3DS cartridge talk to each other. I would like to take this opportunity to also include the 3DS itself in the conversation to illuminate which part of which device performs which step. I will then proceed to outline where I think the corresponding design decisions originate. Finally, I will conclude with some concrete ideas for improvement. But first, we need to talk about parallel universes This protocol makes no sense unless you have a basic overview of the 3DS AES engine. The 3DS AES engine can load 128-bit AES keys in two ways: Using key-derivation from a keyX and keyY (officially called KeyId and KeySeed, respectively). Directly specifying a full AES key. The key derivation from a keyX and keyY works as follows: AES key = (((keyX ROL 2) XOR keyY) + C1) ROR 41, where ROL is left rotation on a 128-bit

ITGamesInfodump

Reconstructing the 3DS Bootstrapping Process at the Factory

Forbidden Tempura 5/13/2024

Motivation The Nintendo 3DS was a fairly popular console. In spite of that, surprisingly little is known about how it is put together at the factory. Working with information that was uncovered during the so-called Gigaleak, I will try to recover as much information as I can about the manufacturing process up and until the point the 3DS is able to complete a normal boot sequence. One-Time Programmable (OTP) region Every 3DS ships with 0x100 of one-time programmable persistent memory at 0x10012000-0x10012100, containing console-unique keys and information. This obviously has to occur before any normal firmware runs on the system because significant amounts of all data written would fail to account for console-unique information and thus the encrypted values would be all encrypted for the wrong keys. An interesting observations: ctr.7z (SHA-256: 8b05072361254437277576d53c08b95e5f076c6b33a2871fad74eaa5561d1d38) ctr/sources/bootrom/CTR/private/build/bootrom/ctr_bootrom/ARM9/main.c has a pr

ITGamesInfodump
Powered by Wave