SSH permission denied on port 22 in an Ubuntu 24.04 home lab typically stems from misconfigured authentication methods, incorrect file permissions on the server, or firewall blocks rather than simple password failures. This guide details how to diagnose the specific error by checking SSH service status, verifying key-based authentication settings in
/etc/ssh/sshd_config, and ensuring proper ownership of the
.ssh directory to restore secure remote access.
Diagnosing the Service State
Before altering configuration files, verify that the SSH daemon is actually running and listening on port 22. In Ubuntu 24.04, the system uses systemd to manage services. You can check the status using the command
systemctl status ssh. If the service is inactive or failed, start it with
sudo systemctl start ssh and enable it to start on boot with
sudo systemctl enable ssh.
It is crucial to use the correct service name. While older tutorials might reference
sshd, modern Ubuntu systems typically register the service as
ssh.service. Using the wrong name will result in a "Unit not found" error, wasting time during troubleshooting. Additionally, ensure that the firewall allows incoming connections on port 22. The UFW (Uncomplicated Firewall) is the default in Ubuntu. Run
sudo ufw status to see if port 22 is listed as allowed. If it is not, enable it with
sudo ufw allow 22/tcp.
For deeper inspection, you can check the logs for immediate errors. Use
sudo journalctl -u ssh -e to view recent entries related to the SSH service. Look for lines indicating authentication failures or configuration parse errors. This step helps distinguish between network issues and server-side configuration problems.
Verifying Authentication Methods
The most common cause of "Permission Denied" when connecting via SSH is a mismatch between the client's offered credentials and the server's accepted methods. Open the main configuration file at
/etc/ssh/sshd_config using a text editor like
sudo nano /etc/ssh/sshd_config. Search for the line containing
PubkeyAuthentication. Ensure this directive is set to
yes. If it is set to
no, public key authentication will be rejected regardless of whether your key is present.
Similarly, check the
PasswordAuthentication setting. If you are trying to log in with a password but this is set to
no, you will receive a permission denied error. For security best practices in a home lab, it is often recommended to disable password authentication after confirming key-based login works, leaving only
PubkeyAuthentication yes. After making any changes to
sshd_config, you must restart the service for them to take effect. Execute
sudo systemctl restart ssh to apply the new configuration.
If you recently changed these settings, ensure you have another way to access the server, such as a local console or VNC, in case you lock yourself out. Modifying SSH configuration remotely without a backup access method carries significant risk. If you cannot connect after restarting, revert the changes using your alternative access method.
Correcting File Permissions and Ownership
SSH is extremely strict about file permissions to prevent unauthorized access to private keys. Even if the correct key is present, incorrect permissions will cause the server to ignore it silently, resulting in a permission denied error. On the Ubuntu server, navigate to the user's home directory and check the permissions of the
.ssh folder and its contents.
Run the following commands to fix common permission issues:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh
The
.ssh directory must have permissions set to 700, meaning only the owner can read, write, and execute. The
authorized_keys file inside must be 600, allowing only the owner to read and write. Any deviation from these standards, such as world-readable permissions, will cause SSH to refuse authentication for security reasons. It is a frequent misconception that home directory permissions alone cause this issue; while they matter, the specific permissions of the
.ssh directory and its files are the primary culprits for key-based failures.
Ensure that the ownership matches the user attempting to log in. If the files are owned by root but you are trying to log in as
ubuntu, the connection will fail. The
chown command above ensures that all files within the
.ssh directory are correctly assigned to the current user.
Client-Side Troubleshooting
Sometimes the issue lies with the Windows 10 client rather than the Ubuntu server. When using tools like PuTTY or the built-in OpenSSH client in Windows PowerShell, ensure that the correct private key is being loaded. If using PowerShell, you can specify the identity file explicitly using the
-IdentityFile parameter. For example:
ssh -i C:\path\to\private_key user@server_ip.
Verify that the public key was correctly appended to the server's
~/.ssh/authorized_keys file. Copying and pasting manually can introduce invisible characters or line breaks that break the key format. It is safer to use the
ssh-copy-id utility if available, or carefully paste the key content ensuring it is on a single line. Check for trailing spaces or newlines in the
authorized_keys file that might corrupt the key string.
If you are still experiencing issues, try connecting with verbose output enabled. Use the command
ssh -v user@server_ip on your Windows machine. The verbose flag provides detailed information about the negotiation process, helping you identify exactly where the handshake fails. Look for messages indicating "Authentications that can continue" and "Next authentication method." This output reveals whether the server is offering public key authentication and why your client's offer was rejected.
For more detailed guidance on initial setup, refer to our article on
Unable to SSH into Ubuntu Server: Log in Locally First. Additionally, if you suspect broader configuration issues affecting multiple services, check
Misconfigured Files: Web Labs, SSH Server, ping, traceroute, and Web Apps Not Working on Main VM (SSH via Browser Works).
Frequently Asked Questions
Why does SSH work locally but not remotely?
This usually indicates a firewall configuration issue on the Ubuntu server blocking external traffic. Ensure that UFW or iptables allows incoming connections on port 22 from your laptop's IP address. You can test this by temporarily disabling the firewall with
sudo ufw disable to see if connectivity is restored, then re-enable it with the correct rules.
Can I use a different port for SSH to avoid permission denied errors?
Changing the port does not resolve permission denied errors caused by authentication failures. However, it can help bypass ISP blocks or basic network filters. To change the port, modify the
Port directive in
/etc/ssh/sshd_config and update your firewall rules accordingly. Remember to specify the new port when connecting from your client.
What should I do if I locked myself out of SSH?
If you cannot connect remotely, you must use physical access or a virtual console provided by your hypervisor. Log in locally, revert the changes made to
sshd_config, and ensure the SSH service is running. Avoid disabling password authentication entirely until you have verified that key-based authentication works reliably.
Does SELinux affect SSH permissions on Ubuntu?
Ubuntu does not use SELinux by default; it uses AppArmor. Therefore, SELinux contexts are not the cause of SSH permission denied errors on standard Ubuntu installations. Focus instead on standard Linux file permissions and SSH configuration directives. If you have installed additional security modules, check their logs for denials.
How do I generate a new SSH key pair on Windows?
Windows 10 and 11 include OpenSSH client tools. You can generate a new key pair using the command
ssh-keygen -t ed25519 in PowerShell. This creates a public and private key in the
%USERPROFILE%\.ssh directory. Copy the content of the
.pub file to the server's
authorized_keys file to establish trust.