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 Internet-facing 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), and logging in as a lowly user, 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 to 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, log out, and we’ll generate our key (it doesn’t have to be done on the server). If it doesn’t work, check the logs on the server for errors with journalctl _COMM=sshd . To generate a 2,048-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 after. 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 that is safely guarded by the user. Both keys are used during the login process to authenticate the user by some mathematical sorcery. This means that forcing key-based login entails carrying your private key around with you wherever you go. Different people will tell you different things about what is the best way to do this. Basically, if you choose to keep it on a USB stick, make sure you don’t go leaving that stick on the train/ bus/horse-drawn carriage.
Running ssh-copy-id user@192.168.1.100 adds 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, you can 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 ), there is no access for you. If you do copy your private key, ensure that it is only readable by your user (i.e. it has file permissions 600), otherwise SSH shouts at you for being insecure. Since filesystems commonly used on USB sticks (FAT32 and NTFS) don’t support Linux permissions, you 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 is picked up automatically, but it can also be renamed, or stored elsewhere—in which case, you 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 prevents 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 (8022, for example) to our TCP port 22 on our server, 192.168.1.100.