Home server/Remote access

• Blurb about remote access, ssh, putty (lol), sftp, etc

SSH Keyfile authentication

We are going to use ssh & ssh-keygen in this tutorial because its consistently available on almost all platforms, including GNU/Linux, BSD, and OSX (by default), and Windows (You're not going to use wangblows and also worry about NSA backdoors are you?).  You can also use PuTTY if you need a GUI crutch or something else entirely, but if you were a tard like that, you probably shouldn't use this page, amirite?

OpenSSH includes a program called ssh-keygen. To generate a public/private key pair run:

ssh-keygen -t ed25519 

With ed25519 the default bitsize is plenty secure (the -b flag is ignored for ed25519 anyways) - nobody's gonna crack that shit easily, the NSA infiltrated the RSA, and DSA is old and insecure, so fuck that. Use the default locations to store your key and enter a strong password when prompted, this is not meant to authenticate you against the SSH server, but to keep the private key secure in case it's stolen from your client machine. When done, it will output 2 files (id_ed25519.pub and id_ed25519) to ~/.ssh. To use the keys for ssh authentication just copy id_ed25519.pub to .ssh/authorized_keys in the home directory of faggot on your server.

use sftp and log in as your non-root user. Then do this:

put .ssh/id_ed25519.pub

you can exit sftp, now use ssh to log in as your non-root user. Then do this:

mkdir .ssh && cp id_ed25519.pub .ssh/authorized_keys && rm id_ed25519.pub

Now take ownership of it:

chmod 600 ~/.ssh/authorized_keys

DO NOT EXIT SSH YET, but open a second ssh session and connect to your server. If it all goes well, your login will look something like this:

Using username "faggot".
Authenticating with public key "ed25519-key-########"

Assuming that works, close your previous ssh session and do this:

sudo nano /etc/ssh/sshd_config

You can change the SSH port here to a random number - that's optional though, because hacker bots are gonna find it anyhow. But if you do change it don't forget to use -o port=#### when loging in as well.

But DO make the following changes:

PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM no

Add the following to the bottom if missing:

UseDNS no
AllowUsers faggot

If you have additional users, put a space after "faggot" and add the next user, and so on if you have more.

Save these changes and restart your SSH server. On Debian, or any other system using systemd, it would be:

sudo systemctl restart sshd

If you are using sysvinit or OpenRC setup it would be:

sudo /etc/init.d/ssh reload

BOOM. Assuming all went well, you have now set up your shell so that 1) "root" cannot log in, 2) ONLY "faggot" can log in, and 3) "faggot" can ONLY log in using their private key file instead of a password. You'll still want to set up and install fail2ban or similar to secure things further.

Oh, and don't lose that private key file. You cannot recreate it, so losing it means you are doomed. Back it up in multiple places. You may wish to place a copy on a floppy drive (if you're a time-traveller from 1995) or USB stick as well, for safekeeping.

fail2ban

fail2ban monitors your log files (any of them, not just SSH). If it sees too many login failures, it bans the offending IP for as long as you configure it to. It won't prevent a distributed brute-force attack, but it will help a LOT. With the default settings, 3 failed SSH logins trigger a 10 minute ban for that IP. This makes brute-forcing very difficult. Usually hackers see the ban and move on, they don't bother even waiting for the 10 minutes to run out.

• Secure your server with fail2ban

sudo apt install fail2ban

fail2ban comes with a bunch of rules already set up. To see these, type sudo fail2ban-client -d (fail2ban runs as root so you won't get anything without sudo). For best results, the jails should be reviewed and fine tuned. There is a manual here: http://www.fail2ban.org/wiki/index.php/MANUAL_0_8

fail2ban keeps a log where it records IPs it banned. You can see it with nano /var/log/fail2ban.log. After a few days, a bunch of Chinese IPs should pop up.

To quickly analyze the banned IPs, run grep Ban /var/log/fail2ban.log. Paste the resulting lines into text editor of your choice and replace the regex .*Ban with an empty string. You will now have the list of IPs. Paste these into a batch geolocator tool like this one.

Use Fail2Ban (and/or DenyHosts) and perhaps a redundant computer in the DMZ. Also never use passwords, only keyfiles.

fwknop - Single Packet Authorization

Normally, your server needs to keep a port open for each service you want to provide. However, hackers love trying to break in the moment they find an open port.

SPA solves the problem by keeping ports close when not in use. How does the server know to open them when you need to talk to it? You pick a port, say 12345, to use for SPA. The server listens on that port but never replies, so there is no way to tell that it's open (and everything else is closed). Every packet arriving on 12345 is actually inspected, the server is waiting for a packet that was encrypted with the correct key. Once a valid packet is detected, the server opens up the ports you need for a few minutes, letting you connect, and then closes them again (you stay connected).