Disable password authentication on your NixOS home server by setting
services.openssh.passwordAuthentication to false in your configuration. This forces all clients, including new machines, to use SSH key-based login, significantly enhancing security against brute-force attacks while streamlining access for authorized devices.
Why Switch to Key-Based Authentication?
Password authentication relies on something you know, which is susceptible to guessing, phishing, and credential stuffing attacks. Even strong passwords can be compromised if they are reused across services or intercepted via keyloggers. SSH key-based authentication utilizes asymmetric cryptography, relying on something you have (your private key). This method is exponentially more secure because the private key never leaves your local machine and cannot be guessed through dictionary attacks. For a home server that may be exposed to the internet, this single change drastically reduces the attack surface. It also eliminates the need to type complex passwords repeatedly, improving workflow efficiency when managing multiple systems.
Configuring NixOS for Key-Only Access
NixOS manages its entire system state through a declarative configuration file, typically located at
/etc/nixos/configuration.nix. To enforce key-based authentication, you must modify the OpenSSH service settings within this file. The specific option controlling this behavior is
services.openssh.passwordAuthentication. By default, this might be true or unset, allowing both methods. You need to explicitly set it to
false. Additionally, ensure that public key authentication is enabled, which is usually the default but should be verified.
Open your configuration file using a text editor such as
nano or
vim. Locate the
services.openssh section. If it does not exist, create it. Add the following lines:
services.openssh.enable = true;
services.openssh.passwordAuthentication = false;
services.openssh.permitRootLogin = "prohibit-password";
The
permitRootLogin setting is crucial. Setting it to
"prohibit-password" allows root login only via keys, preventing password-based root access while still permitting administrative tasks if necessary. However, best practices suggest avoiding root login entirely and using a regular user with
sudo privileges. After making these changes, rebuild your system configuration by running
sudo nixos-rebuild switch. This command applies the new settings immediately. Do not close your current terminal session until you have verified that you can connect from another machine, as losing connectivity could lock you out.
Generating and Deploying SSH Keys
Before disabling passwords, every machine that needs access must have an SSH key pair generated and added to the server’s authorized users. Start on the client machine (the new computer you want to add). Generate a key pair using the
ssh-keygen command. It is recommended to use Ed25519 keys for better performance and security compared to older RSA keys.
Run the following command on the client:
ssh-keygen -t ed25519 -C "[email protected]"
Press Enter to accept the default location (
~/.ssh/id_ed25519) and optionally set a passphrase for an extra layer of security. Once generated, copy the public key to the NixOS server. Use the
ssh-copy-id utility, which handles the placement of the key into the correct directory automatically.
ssh-copy-id username@server_ip_address
If
ssh-copy-id is unavailable, manually append the content of
~/.ssh/id_ed25519.pub to the
~/.ssh/authorized_keys file on the server. On NixOS, it is often cleaner to manage authorized keys declaratively in
configuration.nix using
users.users..openssh.authorizedKeys.keys, especially for headless servers where manual copying is error-prone. This approach ensures that key management survives reboots and configuration rebuilds without manual intervention.
Managing Multiple Machines and Security Risks
As you add more machines to your home server, managing keys becomes critical. Each client should have its own unique key pair. Never share private keys between devices. If a device is lost or compromised, revoke access by removing its corresponding public key from the server’s authorized keys list. This granular control is one of the primary advantages of key-based authentication.
Be aware of the risks associated with disabling password authentication. If you lose your private key or forget the passphrase, and no backup mechanism is in place, you will be permanently locked out of the server. Always maintain a physical console access method, such as connecting a monitor and keyboard directly to the server, or using a remote management interface like IPMI or iLO. This serves as a fallback recovery path. Additionally, consider implementing fail2ban or similar intrusion prevention tools to block IPs that attempt excessive connection failures, even if they are using keys, to mitigate distributed denial-of-service attempts targeting your SSH port.
For further reading on related SSH configurations, see
SSH Servers: Can They Use Push Authentication for Login? and
Troubleshooting SSH with Private Key.
Frequently Asked Questions
What happens if I disable password auth before adding my key?
You will be immediately locked out of the server if you do not already have a valid key configured. Always verify that your new key works from a separate terminal window before flipping the switch in your NixOS configuration.
Can I still use password authentication for SFTP?
No, disabling password authentication for SSH generally affects all subsystems relying on that authentication method, including SFTP. Ensure your SFTP clients are configured to use key-based authentication as well.
How do I recover access if I lose my SSH key?
Recovery requires physical access to the server. Boot into a live USB environment or use the GRUB menu to drop into a root shell, then edit the
authorized_keys file or reset the root password via single-user mode if possible.
Is Ed25519 better than RSA for home servers?
Yes, Ed25519 keys are smaller, faster to generate, and less prone to implementation errors than RSA. They provide equivalent or better security with much shorter key lengths, making them ideal for modern SSH setups.
Should I allow root login via SSH keys?
It is safer to disable direct root login entirely and use a standard user account with sudo privileges. This provides an audit trail of individual actions and prevents attackers from targeting the root account directly, even with key-based access.