Securing Linux Servers by Disabling Password Authentication

Logging into Linux servers with SSH using simple username and password credentials is standard practice thanks to its convenience. But this reliance on basic passwords opens substantial security risks that are increasingly unacceptable for servers holding sensitive data and workloads. A vastly more secure model is to fully disable password-based authentication and only allow access through SSH keys.

In this comprehensive guide geared towards Linux system administrators, we will explore the risks of passwords, the benefits of SSH key-based logins, and multiple methods to disable password authentication including:

1. Configuring SSH daemons to block password logins
2. Enforcing public key-based SSH authentication
3. Removing or disabling SSH services completely
4. Supplementary controls like firewall rules and TCP Wrappers

Here is a quick table comparing password and SSH key authentication models before we dive into practical steps and configurations:

Security Feature	Password Authentication	SSH Key Authentication
Resilient to Offline Attacks	No	Yes
Susceptible to Brute Force	Yes	No
Information Exposure Risk	Yes	No
Multi-Factor Capable	No	Yes
Per User or Device Controls	No	Yes

SSH Attack Landscape and the Risks of Password-Based Auth

To understand the security benefits of disabling password authentication, it helps to examine the prevalence of attacks on SSH and the role of weak credentials. Some key statistics on SSH threats:

• SSH brute force attacks account for over 93% of all remote login attempts on Linux servers per Imperva research.
• The median number of SSH password guessing attempts per attacked account is approximately 120,000 per Gartner.
• Once credentials are compromised, 67% of breaches involve the use of stolen privileged credentials like SSH passwords per Verizon’s 2022 DBIR.

Table: Comparison of SSH Attack Types

Attack Type	Description	% of SSH Attacks
Brute Force	Repeated login attempts guessing passwords	93%
Exploiting Vulnerabilities	Flaws in SSH software or configuration	5%
Protocol & Encryption Attacks	Downgrade encryption or alter packet flow	2%

The vast majority of attacks aim to guess valid password credentials. With enough attempts and time, poorly constructed passwords can eventually be cracked. Compromised passwords then enable lateral movement throughout the network.

Furthermore, passwords sent over a network for remote authentication are susceptible to interception through man-in-the-middle attacks. Once stolen, the credentials continue granting access until changed across all systems.

Table: SSH Authentication Security Comparison

Password Authentication	SSH Key Authentication
Passwords prone to guessing	Keys extremely difficult to brute force
Passwords sent over network	Keys never exposed over channels
Single shared credential	Unique keys per client and user
Limited configuration options	Extensively configurable for hardening
No multi-factor authentication	Supports multifactor with certificates

In summary, default password authentication leaves two major gaps in SSH security – disclosure of secrets and susceptibility to guessing. Disabling this mechanism forces substantially stronger controls around access.

Step 1 – Disabling SSH Password Authentication

To close security gaps introduced by basic password authentication, we need to fully disable the mechanisms allowing it. This is done by modifying the OpenSSH server daemon‘s (sshd) main configuration file.

Begin by opening /etc/ssh/sshd_config with root privileges:

sudo nano /etc/ssh/sshd_config

Look for the PasswordAuthentication directive – by default this will be set to yes permitting password logins:

PasswordAuthentication yes

Change this to no to disable SSH password authentication:

PasswordAuthentication no

Alternative: Disable Root SSH Logins

For additional security, consider explicitly disabling SSH access to the root administrative account if general users do not require direct root shells:

PermitRootLogin no

Save sshd_config after making authentication changes.

The final step is reloading the SSH service to have changes take effect:

sudo systemctl restart ssh

At this point any attempts to login via SSH password will be rejected for all accounts. Only SSH key-based authentication requests will be processed moving forward.

Step 2 – Configuring SSH Key Authentication

With password-based authentication now blocked, logging in requires SSH key-based mechanisms for access control and identity verification.

SSH key pairs work by having:

• A private key stored only on the client device
• A public key added to user accounts on the server

In this asymmetric cryptography model, the private key generates encrypted credentials only decryptable by its respective public key. This proves possession of the private key without ever directly exposing it over networks.

Here is a diagram of how SSH keys are used for authentication without revealing secrets:

(Image credit: SSH.com)

To put this into practice, client machines attempting to access the server must locally generate SSH key pairs:

ssh-keygen -t rsa -b 4096

The flags specify an RSA key type using a robust 4096 bit length. Accept the default location to store the keys or provide a path like ~/ssh_keys/my_key.

This outputs a private key in id_rsa and a public key named id_rsa.pub under .ssh/ in the current user‘s home directory.

With keys generated locally, we need to install the public key on the server in each user‘s ~/.ssh/authorized_keys list:

ssh-copy-id username@server_ip

You will be prompted for the account‘s password one last time to install the public key.

Now that user can SSH into the server using the locally stored private key instead of sending a password.

For improved security, consider adding a passphrase to encrypt the private key itself as well in case it is ever compromised.

SSH Key Best Practices

Properly managing SSH keys is essential to maintaining security when relying on key-based authentication instead of passwords. Here are some best practices:

• Use passphrase protection on private keys
• Control access permissions on private keys (400 or 600)
• Limit key lifetime through expiration dates and rotation policies
• Store private keys on secure media like encrypted drives or hardware tokens
• Backup private keys to allow recovery but prevent inappropriate access
• Designate specific keys per access scenario like individual servers
• Have emergency revocation procedures for compromised keys
• Frequently audit authorized_keys files for anomalies

Adhering to strict SSH key management controls prevents abuse of authentication mechanisms by attackers who gain access to clients or uncovered keys.

Now let‘s look at fully removing SSH as an option when it poses unnecessary risk.

Step 3 – Removing the SSH Daemon Entirely

In highly secure environments like financial systems, allowing any SSH connectivity introduces unacceptable risks. The attack surface can be reduced by removing SSH software and relying on other remote access systems better aligned to specific risks.

Begin by listing any active SSH connections:

sudo lsof -i :22

If output reveals important ongoing SSH sessions, discontinuing SSH at this stage can disrupt operations.

Otherwise move forward removing OpenSSH:

sudo apt purge openssh-server

This eliminates exposures from SSH without the complexity of managing its extensive configuration options. Alternative remote access tools include:

• Remote Desktop – Graphical access without command lines
• VPN Tools – Protect all traffic instead of just SSH flows
• Specialty Protocols – Custom encrypted protocols tailored for specific systems

The downside is losing encrypted command line access and automated SSH scripts. Thoroughly review if SSH is operationally critical before removal.

Supplementary Access Controls

In addition to disabling SSH password authentication and enforcing public key mechanics only, further access controls can frustrate attackers and limit lateral movement after breaches. Common methods include:

Firewall Rules

Restricting what source IP addresses can attempt to connect to SSH via host firewall policies prevents unauthorized external probing and limits failure points:

# Allow only internal office subnets
iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP

TCP Wrappers

TCP Wrappers like tcpd selectively filter source IPs attempting to contact SSH even if firewall policies permit the port:

# /etc/hosts.allow

sshd : 192.168.1.0/24 : ALLOW
sshd : ALL : DENY

Public Key Certificates

Require signed certificates from a trusted authority to validate public keys. This limits impact of compromised user keys granting permanent backdoor authentication.

Investing in these mechanisms on top of strict key-only access with passwords disabled institutes overlapping controls preventing circumvention by malicious actors. Even if one mechanism fails or is misconfigured, secondary protections prevent exploitation.

Defense in Depth SSH Access Control Layers

Tradeoffs Between Convenience & Security

Reviewing protection mechanisms and attack statistics paints a picture where SSH password authentication poses substantial risks for administrative server access. Yet some organizations continue permitting passwords over purely key-based controls.

Reasons for Allowing Passwords

• Users familiar with password entry – Easy administer without client software
• Shared accounts across teams – Single credential instead of authorizing keys
• 3rd party external access – External vendors without ability to manage keys
• Emergency access – Recovery when locked out of key-based system
• Legacy protocols – Ingrained dependence on password-based tooling

Enabling SSH passwords because "that‘s how we‘ve always done it" is an increasingly fragile position as attackers automate credential stuffing and password guessing.

The better path is accepting the learning curve around strictly SSH key-driven access with no fallback to convenience passwords. Doing so almost categorically halts common brute force campaign technologies. Yes it requires more planning and user training, but closing vulnerabilities weakening multi-million dollar systems is worth the growing pains.

Conclusion

While permitting SSH password authentication allows easy access in legitimate situations, the credentials eventually get exposed to attackers – it‘s often a matter of "when" not "if." Eliminating this vector forces utilizes hardware-backed asymmetric cryptography.

Combining default denial of SSH password logins with firewall rules, TCP Wrappers, and other controls institutes overlapping defenses preventing unauthorized access. This layered model ensures protections remain even if individual components get misconfigured or exploited.

Some administrators still opt for basic passwords out of preference or convenience. But as computing power increases, so does the speed of password guessing and necessecity of multi-layer controls. For modern Linux servers holding sensitive data or mission critical workloads, disabling password authentication provides a foundational security control that thwarts common attacks. Yes managing keys introduces some overhead, but compared to dealing with the fallout of breaches, it is a small price that pays dividends in risk reduction.