To access from the remote, start from installing the ssh server. Once ssh is available, tweak some security configurations.
Physically accessing the server every time is not a usual solution. Normally we access the server via ssh connection from the other terminals.
As the first step, I start from installing the ssh server.
Log in as root, then install ssh.
# apt install ssh
The system will ask you to install much more than the package ssh, according to the dependency information. Just answer “y” to proceed. This dependency control always happens and you don’t have to care about it most of the time.
That’s all for now. Just logout and set up your usual terminal to access the server via ssh. (Security enhancement will be set later.)
Set up an ssh client on the computer you mainly use. (Please search for the suitable client for your environment. Maybe Putty will be good for your first try if you don’t have any idea what to choose.)
If your desktop environment is Linux (probably not though), it’s easy to generate the key pair.
$ ssh-keygen -t ed25519
This will generate the latest “ed25519” private key and public key. Anyhow please make your own public key according to your environment.
After logging in to the server, store your public key to ~/.ssh/authorized_keys
$ mkdir ~/.ssh $ chmod 700 ~/.ssh $ vi ~/.ssh/authorized_keys ~~ Copy & Paste your public key ~~ $ chmod 600 ~/.ssh/authorized_keys
“vi” is a powerful text editor, but you can do nothing without learning basics (once you open the file, you can’t exit the application). If you don’t have time, probably “nano” will be the better alternative for the start.
After you store the public key to the ~/.ssh/authorized_keys, log out and try to login again with the public key authentication. (If you successfully log in with the key, the server will not ask you the password to log in like last time.)
If you can log in with the keys, begin the security configuration.
To get the root privilege, use “su” command with the option “-“.
$ su - Password: <input root password> #
Configure the /etc/ssh/sshd_config file to stop password login.
#PermitRootLogin prohibit-password <- Set this to "no" if you like * snip * # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes <- Uncomment the line and set to "no" as shown in next line PasswordAuthentication no #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no <- Make sure this is already set to "no"
After you change the lines, restart the ssh server.
# systemctl restart ssh
Linux has “iptables”, which is a powerful firewall but really complicated. “ufw” is a wrapper to help us set up iptables with easy commands. If your service provider gives you the firewall as a service, then you can have a choice to use it instead.
# apt install ufw
After installing ufw, enable it and start setting. It will alert the existing connection will be cut off, but normally it doesn’t happen. If you are kicked out, unfortunately, access the server physically to continue the configuration.
# ufw enable Command may disrupt existing ssh connections. Proceed with operation (y|n)? y Firewall is active and enabled on system startup
Start from shutting all ports, then open what you need. Currently, only ssh port is required to be open to the public.
# ufw default DENY Default incoming policy changed to 'deny' (be sure to update your rules accordingly)
# ufw allow 'OpenSSH' Rule added Rule added (v6) # ufw reload Firewall reloaded
After you install any software that needs to accept inbound connections, don’t forget to allow them.
Additionally, ufw log is written in /var/log/ufw.log, as well as syslog and kern.log. To avoid the syslog and kern.log filled with UFW BLOCK logs, tweak /etc/rsyslog.d/20-ufw.conf. Just uncomment the last line.
# Log kernel generated UFW log messages to file :msg,contains,"[UFW " /var/log/ufw.log # Uncomment the following to stop logging anything that matches the last rule. # Doing this will stop logging kernel generated UFW log messages to the file # normally containing kern.* messages (eg, /var/log/kern.log) & stop <- Uncomment this line
Now the ssh server is running and port 22 is open. This means a bunch of malicious login attempts.
fail2ban will find out such attempts from the ssh log file and ban that kind of IP address for a while.
# apt install fail2ban
It works nicely with SSH port(22) by default. Just installing fail2ban is enough for the least protect.
Additionally, there is a 'recidive' preset for the continuous attacker. If the attacks continue even after the ssh (or other filters) ban, the ban period will be extended to 1 week.
Add recidive.conf in /etc/fail2ban/jail.d/ to enable it.
[recidive] enabled = true
Then restart fail2ban.
# systemctl restart fail2ban
You can configure to watch other ports if you like.
Always using the root account is not recommended. "sudo" command is used to delegate the privilege to a specific user.
# apt install sudo # adduser username sudo
Adding a user to the group “sudo” will allow that user to use this command.