Getting remote access
Control your server by dynamic DNS and forwarding ports.
Being able to access your server from anywhere in the world can be very handy, but running internetfacing services carries risks. If we allow outside access to the SSH service, then we really should have strong passwords, or (better) use keys.
It’s reasonable to disable access to the root account (if you set a password for it during the install, otherwise it’s already disabled), instead logging in as a lowly user and using sudo for privileged operations. This is controlled with the PermitRootLogin setting in /etc/ssh/sshd_config which you can set to No or, if you want to allow root to log in using a key, prohibit-password (the default on Debian). It’s probably a good idea to check that SSH is working first though, so try and log in from another machine: $ ssh user@192.168.1.100
where user is your username on the server (we’ll use this username/IP address combination throughout). If that works then logout and we’ll get on with generating our key (it doesn’t have be done on the server). If that doesn’t work check the logs on the server for errors with journalctl _ COMM=sshd . To generate a 2048-bit RSA key pair run the command ssh-keygen while logged in to another machine as your user, we’ll copy it to the server afterwards. Accept the default location and choose a password for your key. This adds an extra layer of security in the event the key is stolen.
SSH key logins work by having a public key (it doesn’t matter if anyone sees it) on the server and a private key safely guarded by the user. Both keys are used during the login process to authenticate the user by some mathematical sorcery. Thus forcing key-based login entails carrying your private key around with you wherever you go. Different people will tell you different things about how is the best way to do this. Mostly if you choose to keep it on a USB stick then don’t go leaving that stick on the train/bus/horse-drawn carriage.
Running ssh-copy-id user@192.168.1.100 will add our public key from the default location (~/. ssh/id_rsa.pub) to the file /home/user/.ssh/authorized_keys on the server. This can be done manually too, but why waste keystrokes? We can test it works like so: $ ssh user@192.168.1.100
All going well we should not be asked for a password. If you want to disable password logins entirely, add the directive PasswordAuthentication no
to /etc/ssh/sshd_config. But doing so means that if you don’t have access to your private key (in the file ~/.ssh/id_ rsa ), then there will be no access for you. If you do copy your private key, ensure that it is only readable by your user (ie has file permissions 600), otherwise SSH will shout at you for being insecure. Since filesystems commonly used on USB sticks (FAT32 and NTFS) don’t support Linux permissions, you’ll need to copy the key off such media (and then run chmod 600 id_rsa ) before attempting to log in. The private key can be copied to the .ssh directory on the machine you’re working on, in which case it will be picked up automatically, but it can also be renamed or stored elsewhere, in which case you’ll need to use ssh -i /path/to/key .
There’s one final step to make remote access work and that’s to tell your router to forward SSH traffic from the WAN to your home router. Our server listens on the default port ( 22), but we can have it listen on a different port, which at least will prevent our server being found by robotic port scans. How to configure this varies from router to router, but the goal is to forward external traffic from an obscure TCP port (e.g. 8022) to our TCP port 22 on our server, 192.168.1.100.