Based on Debian 10 "Buster" environment.

ssh and security

To access from the remote, start from installing the ssh server. Once ssh is available, tweak some security configurations.

ssh server

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.)

Access from the usual terminal

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.)

Setting the public key

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.

ssh server configuration

Get root privilege

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

Second level jail

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.

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.

  • If you want to be more restrictive, you can limit the commands available to that user.
  • You need to re-login to apply the new group. In other words, you need to log out and log in again to use sudo command.

Update History


  • Add recidive explanation to fail2ban
  • Remove "banaction = ufw" configuration
    Recidive doesn't work with ufw, and fail2ban doesn't have to use ufw even if ufw is installed.