Remote protocols like SSH and SFTP improve a server's accessibility, but they severely undermine its security.

If an attacker discovers a specific server's IP, they can attempt an SSH connection to that IP. Even without knowing the IP, they can just as easily get in through a domain linked to that IP, since a domain's information — including the IP and even ownership details — can easily be obtained by querying a DNS server.

Therefore, if anyone knows the IP or domain, SSH service port, and account information of the server you're trying to access, they can attempt an SSH connection or cause damage to the server at will.

The moment you expose a domain to the outside world, various connection attempts start coming in from both home and abroad. Attacks from China in particular come in a lot, and you can easily find related experiences and case studies of damage on the internet.

There are simply casual passersby trying to connect to your domain for fun, but some of them have skills sophisticated enough to be considered real attackers, and among those, a tiny minority may even have skills advanced enough to bypass your server's security.

Given the nature of servers — connected to various internal systems and networks — having a server compromised means the safety of all information related to that server can no longer be guaranteed. Even companies that always employ the best possible security measures still suffer breaches sometimes. As a joke, people sometimes say that the resident registration numbers of most citizens are probably already floating around on the internet.

If, like a company, you have someone with a high level of security expertise on staff, you can at least confirm and patch the damage. But those who are insensitive to security or lack sufficient knowledge — small businesses or individuals — often don't even realize their server has been compromised. In severe cases, the server isn't even managed at all, and ends up being used as the attacker's own personal server.

No matter what security measures you put in place, security is always insufficient. But simple measures alone can block a significant portion of the threats mentioned above. As I said, most attempts aren't even worth calling "attacks" — they're more like mischievous pranks, and if a personal server, most of whose data is of relatively low value, has even a baseline level of security, bypassing it is simply a waste of time for an attacker.

To put it simply, imagine you're playing a game and there's a boss with a ton of HP, an annoying pattern, and rewards that are only worth as much as a common mob. You'd sigh every time you reach that section, and the game's community would be flooded with demands to have that boss removed. On YouTube, you'd find a video titled "The 10 Worst Video Game Bosses of All Time" trending in the top 5. On forums, the boss's name would be used as an insult, and various strategies to skip that boss would be actively researched.

In this chapter, we'll turn our server into just such a "bloated HP sponge with no reward and an annoying pattern" boss, so that attackers get disgusted and avoid it.

The protocols that directly affect the file system include SSH and SFTP. Their predecessors, Telnet and FTP, are disabled by default upon OS installation since they don't support SSL. There's no real reason to use those protocols anyway, so we won't cover them here.

Each of these services is managed by the SSH daemon, so they share port 22. Since the default port of these base protocols is fixed, most attack attempts exploit this consistency. Conversely, that means simply changing the service port can easily block a lot of basic attack attempts.

Unlike the default configured port, a port randomly chosen by the server admin can't be traced. Since the maximum port number is 65,535, if you change to a random port, an attacker has to try communicating with every single port just to find the SSH port.

You can either change the service port for SSH and SFTP, or use iptables or router settings to set up port forwarding, mapping an arbitrary external port to port 22.

BASH
sudo vi /etc/ssh/sshd_config

Looking at the file contents, you'll find a commented-out line #Port 22; remove that comment, enter the port you want, and save.

BASH
systemctl restart ssh

Don't forget to restart the SSH service.

If you're hesitant about changing the SSH port, you can instead map it to an arbitrary port used for external connections through port forwarding. You can set this up using iptables.

BASH
 # Add port forwarding
iptables -t nat -A PREROUTING -p tcp --dport 22 -j REDIRECT --to-port [PORT NUMBER]

 # Remove port forwarding
iptables -t nat -D PREROUTING -p tcp --dport 22 -j REDIRECT --to-port [PORT NUMBER]

 # Check port forwarding status
iptables -L

If you're using a router, you can also set up port forwarding from the router itself.

Using iptables, you can also restrict access so that only specific IPs can access a given port. If you connect it with a geoIP plugin, you can manage things by country-specific IP ranges as well — look into it if you're interested. Note that setting this up isn't necessarily simple.

Let's assume an attacker is persistent enough — or lucky enough — to discover the SSH service port I randomly changed and attempts an attack.

For account credentials, they'll typically use a brute-force approach, trying every possible combination of account credentials to attempt a login. To prevent this, systems are often configured so that detecting a certain number of failed login attempts temporarily restricts access, or locks the account until an administrator unlocks it.

The above methods are already good enough, but configuring the server so that login is only possible via an RSA key dramatically strengthens login security.

Even if I know a user's account credentials — even the password — if there's no private key matching the public key registered on the server, login is simply not possible.

The procedure is as follows.

1. Generate an RSA key pair
2. Register the public key on the server
3. Provide the private key file when connecting via SSH or SFTP to log in

When generating an RSA key, you can set a passphrase on the key file. In that case, login requires the passphrase set on that key file. Since the key file's passphrase is separate from the server's account credentials, even if the key file leaks, requiring the passphrase for using the key file prevents actual damage.

BASH
ssh-keygen -t rsa

Use the above command to generate an RSA asymmetric key pair. During generation, it asks for a passphrase for the key file; pressing Enter with a blank field generates the key without a passphrase. In that case, anyone who obtains the key file can use it directly. Conversely, if you set a passphrase, you'll need to enter the specified passphrase to decode and use that key file.

• Private key: /home/username/.ssh/id_rsa
• Public key: /home/username/.ssh/id_rsa.pub

By default, these are generated directly at the paths above.

BASH
ssh-copy-id username@xxx.xxx.xxx.xxx

Use the above command to register the key file on the server. It automatically registers /home/username/.ssh/id_rsa.pub.

BASH
ssh -i [PRIVATE KEY] username@xxx.xxx.xxx.xxx

Use the above command to connect via SSH. You can specify the private key path with the -i option. If you set a passphrase when generating the key, you'll need to enter it; if you didn't set one, you'll log in immediately.

Most likely, you generated the RSA key on Ubuntu and transferred the generated private key to Windows to use for SSH access.

OUTPUT
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for 'C:\\id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "C:\\id_rsa": bad permissions

But when you actually try to use the key file on Windows, if the key file is accessible to too many users, its use is restricted for security reasons. There's only one solution — grant permission only to the user who'll use that key file.

The problem is, because of Windows' convenience features, when the file transfer completes, the necessary permissions are automatically granted, so you have to remove them manually.

You can check the access permissions granted to the file under the key file's [Properties] - [Security] tab. As you can see, access is currently granted to too many users, so change it so only you can access it. Unfortunately, the file has inheritance applied, so it can't simply be deleted. Click the [Advanced] tab at the bottom.

Click the [Disable inheritance] button at the bottom to remove the inheritance relationship. A message will appear; choose [Convert to explicit permissions]. Removing it outright would require manually specifying users, which is tedious.

After that, remove every permission entry except your own account. Save it and try again, and you should be able to log in successfully.

If you've gotten this far, that means login via key file works, which is great — but the problem is that logging in with plain account credentials still works too.

That defeats the purpose of leveraging the strong security of key files. Let's restrict logins to only key-file login, so only those who hold the private key for my server can connect.

※ Configuring this carelessly can lock even yourself out of SSH, so be careful

BASH
sudo vi /etc/ssh/sshd_config

Open the SSH config file and modify the value below. This disables password-based login.

• PasswordAuthentication yes -> PasswordAuthentication no

BASH
systemctl restart ssh

Try logging in after restarting.

BASH
 # SSH with regular login
ssh username@xxx.xxx.xxx.xxx

 # SSH with the key-file method
ssh -i [PRIVATE KEY] username@xxx.xxx.xxx.xxx

Regular login will fail even if you enter the correct account credentials.

I changed the configuration so that SSH and SFTP can only be logged into with a private key.

Even security measures that seem simple at first glance can neutralize the vast majority of actual attacks.

Keys let you protect your server's security much more effectively, but be careful not to lose your key file.