Anyone only needs to know these four elements to access your Linux server: IP address, port, username, and password. Clearly, the security of these four components is the baseline we need to protect. Let’s analyze them one by one:
IP Address: Malicious scripts can randomly attempt and scan IP ranges, so it can be considered public information and cannot be hidden.
Port: If the default port is used, then the port equals 22.
Username: If the default user is used, then the username is root.
Password: There is no default password; it must be randomly generated by the Linux backend or set by you. In other words, if your server is using default settings, three out of the four elements are already known. Thus, the security of your entire server relies on a single password. In this situation:
- If you use a randomly generated password from the Linux control panel, it generally includes a mix of random uppercase and lowercase letters, as well as symbols, making it relatively secure.
- If you choose a weak password like “123456” for easy memorization, breaking into your Linux server would be effortless.
- Even if you select a more complex password that you’ve used elsewhere, it’s not truly secure. You must understand that hackers have tools like password dictionaries containing tens of thousands, hundreds of thousands, or even millions of previously leaked real passwords.
However, it’s important to realize that no hacker actually sits at a computer and manually tries your password one by one. All attack attempts are automated by malicious scripts that work tirelessly 24/7. While you’re asleep, your server may be enduring round after round of attacks.
Once the password is successfully cracked, it means the attacker has all four elements in their possession. The malicious script will swiftly log into the server, gain the highest root control, deploy malicious services, and then use your server for various malicious activities 24/7 (such as mining, spreading viruses, sending spam emails, fraudulent emails, acting as a BT relay, or even serving as a node on the dark web, among other things). If the malicious script is discreet, it can remain relatively hidden. Moreover, newcomers typically don’t monitor Linux login records, process changes, CPU usage fluctuations, or traffic changes, making it difficult to detect a security breach. You might not realize you’ve been compromised until your Linux service provider suspends your account or you receive a legal notice.
Don’t forget that when acquiring a Linux, you likely use real payment information, and when you log into various websites and social platforms, you leave behind your IP address, all of which have direct or indirect ties to your identity. Consequently, once these malicious activities occur, they inevitably become associated with you.
To check SSH login records on a Debian-based system like Debian itself or Ubuntu, you can use the system log files, which typically store SSH login information. The most common log file for this purpose is /var/log/auth.log. Here’s how you can check SSH login records:
- Open a terminal on your Debian system. You may need root or sudo privileges to access the log files.
- Use a text editor or a command-line tool to view the SSH login records. You can use
less,grep, or any other text processing tool of your choice. For example:
sudo less /var/log/auth.logThis command will display the contents of the auth.log file. You can scroll through the file using the arrow keys and quit by pressing q.
- To specifically filter SSH login records, you can use
grep. For example, to view only SSH-related log entries, use:
sudo grep sshd /var/log/auth.logThis command will display only the lines in the log file that contain “sshd,” which is the SSH server daemon.
- To view the most recent SSH login attempts, you can use the
tailcommand:
sudo tail -n 20 /var/log/auth.logThis command will display the last 20 lines of the auth.log file, which typically include the most recent login attempts.
- If you want to monitor SSH login attempts in real-time, you can use the
journalctlcommand if your Debian system uses systemd:
sudo journalctl -u sshThis will show live updates of the SSH service logs. Press Ctrl + C to exit.
Remember that reviewing SSH login records can help you identify unauthorized access attempts and troubleshoot any authentication issues on your system. Ensure that you have appropriate permissions to access log files and only use this information for legitimate system administration purposes.
There are really attempts to login to every Linux server every day. Here is an example:
Sep 11 11:55:15 racknerd-50fa75 sshd[25628]: Disconnected from 61.177.172.179 port 36660 [preauth]
Sep 11 11:55:15 racknerd-50fa75 sshd[25628]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.177.172.179 user=root
Sep 11 11:55:16 racknerd-50fa75 sshd[25631]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.177.172.179 user=root
Sep 11 11:55:18 racknerd-50fa75 sshd[25631]: Failed password for root from 61.177.172.179 port 26591 ssh2
Sep 11 11:55:20 racknerd-50fa75 sshd[25631]: Failed password for root from 61.177.172.179 port 26591 ssh2
Sep 11 11:55:23 racknerd-50fa75 sshd[25631]: Failed password for root from 61.177.172.179 port 26591 ssh2
Sep 11 11:55:23 racknerd-50fa75 sshd[25631]: Received disconnect from 61.177.172.179 port 26591:11: [preauth]
Sep 11 11:55:23 racknerd-50fa75 sshd[25631]: Disconnected from 61.177.172.179 port 26591 [preauth]
Sep 11 11:55:23 racknerd-50fa75 sshd[25631]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.177.172.179 user=root
Sep 11 12:00:42 racknerd-50fa75 sshd[25637]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=180.101.88.247 user=root
Sep 11 12:00:44 racknerd-50fa75 sshd[25637]: Failed password for root from 180.101.88.247 port 43097 ssh2
Sep 11 12:00:46 racknerd-50fa75 sshd[25637]: Failed password for root from 180.101.88.247 port 43097 ssh2
Sep 11 12:00:48 racknerd-50fa75 sshd[25637]: Failed password for root from 180.101.88.247 port 43097 ssh2
Sep 11 12:00:48 racknerd-50fa75 sshd[25637]: Received disconnect from 180.101.88.247 port 43097:11: [preauth]
Sep 11 12:00:48 racknerd-50fa75 sshd[25637]: Disconnected from 180.101.88.247 port 43097 [preauth]Changing the default SSH port is a good security practice as it can help deter automated attacks targeting the default SSH port (port 22). To change the SSH port in Debian Linux, follow these steps:
Edit the SSH configuration file: You will need to edit the SSH server configuration file, which is usually located at /etc/ssh/sshd_config. You can use a text editor like nano or vim. For example:
sudo nano /etc/ssh/sshd_configFind the line for the SSH port: Look for the line that specifies the port. It typically looks like this:
#Port 22Remove the # symbol at the beginning of the line if it’s there, and then change the port number to your desired port. For example, to change it to port 2222:
Port 2222Save the changes: In nano, you can save the changes by pressing Ctrl + O, then press Enter, and exit by pressing Ctrl + X.
Restart the SSH service: After making the changes, you need to restart the SSH service to apply them:
sudo systemctl restart sshUpdate the firewall rules: If you are using a firewall like iptables or ufw, don’t forget to update your firewall rules to allow traffic on the new SSH port. For example, if using ufw:
sudo ufw allow 2222/tcpReplace 2222 with the new SSH port number you’ve chosen.
Test the new SSH port: Before you close your current SSH session, open a new terminal and attempt to connect using the new port to make sure it’s working. For example:
ssh username@your_server_ip -p 2222Replace username with your username and your_server_ip with your server’s IP address.
Remember to keep a record of the new SSH port you’ve chosen, as you’ll need it for future SSH connections. Changing the SSH port is just one part of securing your SSH service; it’s also important to use strong passwords, consider key-based authentication, and implement other security measures to protect your server.
It’s a good security practice to disable direct root login and instead create a new user with sudo privileges for server administration. Here’s how you can do that on Debian Linux:
Log in as Root: If you are not already logged in as the root user, you will need to log in as the root user or a user with sudo privileges.
Create a New User: Replace newusername with your desired username.
adduser newusernameYou will be prompted to set a password and provide some information about the new user.
Add the New User to the sudo Group: By adding the new user to the sudo group, they will have administrative privileges.
usermod -aG sudo newusernameDisable Root Login: Open the SSH configuration file again:
nano /etc/ssh/sshd_configFind the line that says PermitRootLogin and set it to no if it’s not already set:
PermitRootLogin noSave and exit the file.
Restart SSH: Restart the SSH service to apply the changes:
systemctl restart sshTest the New User: Log out of your SSH session as the root user and log in using the new user account:
ssh newusername@your_server_ipReplace newusername with the username you created and your_server_ip with your server’s IP address. You should now be able to log in with the new user and use the sudo command to perform administrative tasks.
Disable Password Authentication (Recommended): For improved security, you can consider disabling password authentication and use SSH key pairs instead.
With password authentication disabled and SSH key authentication set up, your server will be more secure.
Remember to replace newusername with your chosen username and your_server_ip with your server’s IP address in the commands above.
Generate SSH Key Pair (if not already done): If you don’t have an SSH key pair, generate one using the following command:
ssh-keygen -t rsa -b 4096Follow the prompts to generate the key pair. The private key will be saved in ~/.ssh/id_rsa, and the public key will be saved in ~/.ssh/id_rsa.pub.
Copy the Public Key to the Server: Use the ssh-copy-id command to copy your public key to the server. Replace username and hostname with your server’s username and hostname/IP address.
ssh-copy-id username@hostnameIf ssh-copy-id is not available, you can manually copy the public key to the server’s ~/.ssh/authorized_keys file:
cat ~/.ssh/id_rsa.pub | ssh username@hostname 'cat >> ~/.ssh/authorized_keys'Disable Password Authentication: Edit the SSH daemon configuration file. Open the file in a text editor:
sudo nano /etc/ssh/sshd_configFind the line that looks like PasswordAuthentication yes and change it to:
PasswordAuthentication noSave the file and exit the editor.
Restart the SSH Service: Restart the SSH service to apply the changes:
sudo systemctl restart sshNow, password authentication is disabled, and only SSH key pairs are allowed for authentication. Make sure you have successfully tested the SSH key authentication before disabling password authentication to avoid being locked out of your system.