View source for 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 <code>/etc/ssh/ssh_config</code> and <code>/etc/ssh/sshd_config</code> respectively. An OpenSSH server can also act as a file server using the sftp client. SFTP enables you to <code>put</code> and <code>get</code> 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 

{{bc|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 <code>~/.ssh/</code> 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 <code>ssh my-server</code>

==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]]

=[http://www.fail2ban.org/wiki/index.php/Main_Page 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.

* [https://www.linode.com/docs/guides/using-fail2ban-to-secure-your-server-a-tutorial/ Secure your server with fail2ban]

 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 <code>sudo fail2ban-client -d</code> (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 <code>nano /var/log/fail2ban.log</code>. After a few days, a bunch of Chinese IPs should pop up.

To quickly analyze the banned IPs, run <code>grep Ban /var/log/fail2ban.log</code>. Paste the resulting lines into text editor of your choice and replace the regex <code>.*Ban </code> with an empty string. You will now have the list of IPs. Paste these into a batch geolocator tool like [http://www.infobyip.com/ipbulklookup.php this one].

=[[Wikipedia:Pork knocking|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).

* [https://help.ubuntu.com/community/SinglePacketAuthorization fwknop - Single Packet Authorization]
* [https://linoxide.com/firewall/knockd-protect-server-port/ 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 [https://portforward.com/ here].

=External links=
* [https://wiki.debian.org/SSH SSH]
* [https://smallstep.com/blog/use-ssh-certificates/ SSH authentication using certificates]
* [https://stinkyparkia.wordpress.com/2014/10/14/remote-unlocking-luks-encrypted-lvm-using-dropbear-ssh-in-ubuntu-server-14-04-1-with-static-ipst/ Unlock encrypted volume using Dropbear]

=See also=
* [[Home server]]
* [[Security]]

[[Category:Tutorials]]