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:
sudo systemctl enable ssh && sudo 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?
First make the ssh directory for your client:
mkdir ~/.ssh
OpenSSH includes a program called ssh-keygen. To generate a public/private key pair run:
ssh-keygen -a 256 -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). You will want to set the permissions for the private key used by the client
chmod 600 ~/.ssh/id_ed25519
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:
put ~/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:
mkdir ~/.ssh cat ~/id_ed25519.pub >> ~/.ssh/authorized_keys rm -rf ~/id_ed25519.pub
Now take ownership of it:
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
DO NOT EXIT SSH YET, but open a second ssh session and connect to your server:
ssh faggot@server -i /dir/to/privatekey/id_ed25519 -o PasswordAuthentication=no -vv
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 open your sshd config to force publickey authentication:
sudo nano /etc/ssh/sshd_config
sshd_config HostKey /etc/ssh/ssh_host_ed25519_key HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_ecdsa_key # Ciphers and keying HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519 KexAlgorithms curve25519-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com MACs hmac-sha2-512,hmac-sha2-512-etm@openssh.com # Only allow incoming ECDSA and ed25519 sessions: HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 PubkeyAcceptedKeyTypes ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519 # Authentication: PermitRootLogin no AllowUsers faggot AdminUser MaxAuthTries 5 MaxSessions 2 AuthenticationMethods publickey PubkeyAuthentication yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no ## Under PAM UsePAM no AllowAgentForwarding no AllowTcpForwarding no AllowStreamLocalForwarding no X11Forwarding no ClientAliveInterval 900 ClientAliveCountMax 0 # override default of no subsystems Subsystem sftp /usr/lib/openssh/sftp-server -f AUTHPRIV -l INFO
Save these changes and restart your SSH server. On Debian, or any other system using systemd, it would be:
sudo service ssh restart
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 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
- Delete known_hosts in your client ssh directory after each authentication during setup until you have your sshd_config setup and a successful public key authentication
- 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.
sudo apt install fail2ban
Copy both fail2ban.conf and jail.conf, fail2ban will update these two files and the local files will supersede these:
sudo cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local && sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
Edit the jail.local and uncomment sshd in the jail section:
sudo nano /etc/fail2ban/jail.local
[sshd] enabled = true port = ssh
Then restart fail2ban:
sudo service fail2ban restart
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).
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.