SSH SEGURITY

Security in SSH is of paramount importance because SSH is a fundamental tool to enable secure remote connections in computing environments.

Segurity for SSH


SSH (Secure Shell) is an essential tool for securely managing servers remotely. However, if not configured properly, it can leave your system vulnerable to attacks. we will learn how to implement good SSH security practices to protect your servers and ensure that only authorized users have access.


Disable Root User


Disable the root user's SSH access and create a new user with root privileges.


Here are the reasons why you should avoid using the root user for SSH access:


Security: The root user has complete privileges and unrestricted access to all files and system configurations. If an attacker gains SSH access to your server as the root user, they would have full control over the entire system, greatly increasing the risk of severe damage or data loss.


Brute Force Attacks: Attackers often attempt brute force attacks to guess the root user's password. Since the root user typically exists on all systems, it is a common target for hackers. Avoiding direct access as the root user reduces the likelihood of such attacks being successful.


Costly Mistakes: Making a mistake while executing a command as the root user could have disastrous consequences. By using a regular user account to access the server, the risk of making critical errors that affect the entire system is minimized.


Activity Logging: If multiple users access the server through SSH using their own accounts, it becomes easier to track activities and actions performed by each user. This is particularly useful in environments with multiple administrators or collaborators.


Additional Security Layer: By disallowing direct access as the root user, an attacker would first need to compromise a regular user account before attempting to elevate their privileges to gain root-level access. This provides an additional layer of security.


First, create user and in you sshd_config set PermitRootLogin in no.


  useradd -m donDiabetes
  passwd donDiabetes
  usermod -aG sudo donDiabetes


in /etc/ssh/sshd_config


  PermitRootLogin no


Limit Login/Access Attempts


By default, you can access the server by making as many password attempts as you want. However, attackers can use this vulnerability to brute-force the server.


in /etc/ssh/sshd_config set MaxAuthTries in 3.


  MaxAuthTries 3


Changing the Default SSH Port


The default SSH connection port is 22. Of course, all attackers know this and therefore, it is necessary to change the default port number to ensure SSH security.


in /etc/ssh/sshd_config set Port in other, example:


  Port 2424


Allow Users


In the context of SSH (Secure Shell), the "AllowUsers" parameter is a configuration option that allows restricting access to an SSH server to specific users. With this configuration, you can set up a whitelist of users who are allowed to connect to the server via SSH, while blocking access for all other users.


The "AllowUsers" option provides an additional layer of security by limiting access only to those users considered trustworthy and who need to access the system via SSH. This is especially useful for servers that require stricter security to reduce the attack surface and minimize the chances of unauthorized access.


  AllowUsers myuser1 myuser2 


Login SSH Key


SSH keys, also known as "SSH keys" or "SSH key pairs," are a set of cryptographic keys used to establish secure and authenticated connections between a client and a server using the SSH (Secure Shell) protocol. SSH keys consist of two parts: the private key and the public key. Here's how they work:


Generating the keys:


The client (e.g., your local computer) generates an SSH key pair: the private key and the public key.

The private key must be kept secret and protected since it is essential for authenticating to remote servers.

Distribution of the public key:


The public key is copied to the remote servers you want to access securely.

The public key is added to the ~/.ssh/authorized_keys file on the remote server. This allows the server to trust the client that possesses the corresponding private key.

Authentication process:


When the client attempts to connect to the remote server via SSH, the server sends a challenge to the client.

The client, to demonstrate that it possesses the private key, uses its private key to sign the challenge and sends the signature to the server.

The server uses the public key stored in authorized_keys to verify the signature sent by the client.

If the signature is valid, the server accepts the connection and allows access to the client.

SSH key-based authentication is more secure than using passwords. Since the private key is required for authentication, even if someone gains access to the client machine, they won't be able to use the SSH keys without the passphrase associated with the private key.


It is crucial to protect your private key properly and avoid sharing or storing it in insecure locations. Additionally, it is recommended to set up a passphrase to further protect the private key, as it adds an extra layer of security in case someone gains physical access to the private key.


Advantages of using SSH keys:


Enhanced Security: SSH key-based authentication provides an additional layer of security compared to passwords. Cryptographic keys are more difficult to guess or compromise, reducing the risk of brute-force attacks or unauthorized access attempts.


No Password Exposure: By using SSH keys, users do not need to enter passwords when connecting to remote servers. This eliminates the risk of passwords being intercepted or recorded by attackers.


Automatic Authentication: SSH keys enable automatic authentication, streamlining the login process to remote servers. Once the public key is set up on the server, users can access it without entering a password each time.


Centralized Management: Administrators can manage public keys from a central server, making access management easier and ensuring that only authorized users have permission to access servers.


Scripting and Automation: SSH keys are useful for automating tasks and processes in scripts and workflows. They can be used to authenticate to servers without requiring manual user interaction.


Cross-platform Support: SSH keys are compatible with various operating systems and environments, allowing their use on a wide range of devices and platforms.


Better Access Control: Having control over who has access to the private key allows administrators to more effectively restrict which users and machines can access remote servers.


Auditable: SSH keys and their activities are auditable, enabling tracking of user access and monitoring of remote connections.


In summary, using SSH keys offers a more secure, efficient, and automated authentication method for accessing remote servers. By eliminating the need for passwords and providing an additional layer of security, SSH keys have become a standard practice in the field of security and system administration.


Create SHH key pair on you devide (Client):


   ssh-keygen


This command will create the public and private key in the directory C:\Users\user\.ssh\ (Window)



Create .ssh folder in you user dir (Server): 


	mkdir -p ~/.ssh



Add Privileges to folter (Server): 


	chmod 700 ~/.ssh


Move id_rsa.pub to server (Client):


    scp -P 2424 id_rsa.pub user@localhost:/home/user/.ssh/id_rsa.pub


SCP (Secure Copy Protocol) is a command used in Unix and Linux systems to securely copy files and directories between a local machine and a remote server or between two remote servers. SCP utilizes the Secure Shell (SSH) protocol to encrypt the data during the transfer, ensuring a secure connection and protecting the information being copied. 

 

In /home/user/.ssh path execute (Server):


  sudo echo id_rsa.pub >> ~/.ssh/authorized_keys


Config ssh file (Server):


  sudo nano /etc/ssh/sshd_config


In your SSH configuration file, set these specific directives with their value (Server):


	
  PasswordAuthentication no 
  PubkeyAuthentication yes
    


Restart SSH services (Server):


sudo systemctl restart ssh