hello friends! new(ish)!
Home server/Remote access
SSH stands for Secure Shell and is a protocol for secure remote login and other secure network services over an insecure network, which basically means you can access your server from your computer over a network and execute commands as if you were typing them on the server itself. OpenSSH, the most popular SSH software, comes with a client and a server, the config files are /etc/ssh/ssh_config and /etc/ssh/sshd_config respectively. An OpenSSH server can also act as a file server using the sftp client. SFTP enables you to put and get files on and off your server, as well as many other things.
Setup
You usually enable the ssh server during the installation. Do this if possible, it is the simplest way.
- If you did not setup ssh to auto start on boot, using systemd type:
systemctl enable ssh && systemctl start ssh
- If that does not work, you need to install OpenSSH with your package manager
sudo apt install openssh-server
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 append the public key (id_ed25519.pub) to ~/.ssh/authorized_keys in the home directory of your admin user on your server.
Using sftp:
mkdir ~/.ssh
put ~/.ssh/id_ed25519.pub
you can exit sftp, now use ssh to log in as your non-root user. Then do this:
echo ~/.ssh/id_ed25519.pub >> authorized_keys
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
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 ssh
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 (id_ed25519). 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.
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.
Port Knocking
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).