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.
• Optionally 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 (If you used the default location). 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 login as admin user:

mkdir ~/.ssh

put ~/.ssh/id_ed25519.pub

Exit sftp, now use ssh to log in as your admin user and append the public key to the authorized keys file:

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 

Uncomment the following and change to 'no':

PermitRootLogin no
PasswordAuthentication no
UsePAM no
X11Forwarding no
UseDNS no

Then allow your admin user:

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.

SSH config file

A config file in the ~/.ssh/ directory enables you to set addresses, keyfiles and aliases for your servers.

sudo touch ~/.ssh/config

sudo nano ~/.ssh/config

Add:

Host my-server
 HostName 198.168.1.88
 User faggot
 IdentityFile ~/.ssh/id_ed25519
 IdentitiesOnly yes

Now you can login using ssh my-server

Troubleshooting

• Check permissions on keys and the ~/.ssh/ directory for your client and server
• Ensure you edit the sshd_config on the server and ssh_config for client
• See Home server/Remote access#Firewall and Ports

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.

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).

• fwknop - Single Packet Authorization
• Knockd

Firewall and Ports

• Don't forget to allow traffic on the ssh port (default 22)

sudo ufw allow ssh

• If you want to access your server from outside your home network you will need to forward port 22 on your router. A guide for port forwarding can be found here.

External links

• SSH
• SSH authentication using certificates
• Unlock encrypted volume using Dropbear

See also

• Home server
• Security