PuTTY Access Denied: How to Fix It

What you're seeing

The connection opens, you enter credentials, and the server answers in the terminal:

login as: root
[email protected]'s password:
Access denied
[email protected]'s password:

It re-prompts after every failure, sometimes as Access denied on its own line, sometimes as part of a keyboard-interactive prompt. Keep failing and the session ends with a "too many authentication failures" disconnect (that error's page covers it).

Two lookalikes are different errors entirely:

• A dialog saying Network error: Permission denied appears before any login prompt. That's not the server rejecting you; it's your own machine blocking PuTTY's outbound connection. Windows Defender Firewall, a third-party antivirus, or corporate endpoint software is stopping putty.exe from opening the socket. Allow PuTTY through the firewall or re-install it unblocked. (If Windows refuses to even launch putty.exe with "access denied", that's the same local blocking, aimed at the program itself.)
• Unable to open connection to COM3: Error 5: Access is denied on a serial session means the COM port is taken or restricted, not a login failure at all. See PuTTY Unable to Open Serial Port.

This page is about the first case: the server heard your credentials and said no.

What's causing this error

sshd checked the username and password (directly or through PAM) and rejected the pair. The real causes, in rough order of frequency:

1. The password is simply wrong. A typo you can't see, the wrong keyboard layout, Num Lock off, or a trailing space when pasting.
2. The username is wrong for this machine. The password may be perfect, but for a different account than the one you typed.
3. Root login is disabled. PermitRootLogin no (or the default prohibit-password) rejects root's correct password every time. This is the big one on cloud servers and Raspberry Pi.
4. AllowUsers, AllowGroups, or DenyUsers in sshd_config excludes the account, so sshd denies it regardless of password.
5. The account is locked or expired: too many failed attempts, passwd -l, or an expired password/account via chage.
6. PAM is failing, so even correct passwords come back as Access denied under keyboard-interactive auth.

How to fix it

Step 1: Rule out the password itself

• Type it slowly in a visible place first (the PuTTY "login as" field, or Notepad), then retype it in the password prompt. The prompt shows nothing while you type, not even asterisks; that's normal.
• Pasting into PuTTY is right-click (or Shift+Insert), not Ctrl+V. Ctrl+V can insert nothing or the wrong buffer, and a paste with a trailing newline or space fails silently.
• Check Num Lock and your keyboard layout if the password contains digits or special characters.

Step 2: Use the right username

The most common "correct password, still denied" case is the wrong account name. Defaults worth knowing:

Step 3: If you're logging in as root, stop

Most servers ship with root SSH login disabled, and the rejection looks identical to a wrong password. Log in as the admin user from the table above, then become root:

sudo -i

To confirm this is the cause, check from a console or an admin session:

sudo grep -i "^PermitRootLogin" /etc/ssh/sshd_config

no rejects root always; prohibit-password rejects root's password but allows a key. Leaving it that way and using sudo is the right call. If you genuinely need password root login, set PermitRootLogin yes and restart sshd, knowing it makes root brute-forceable.

Step 4: Read the server's auth log

The log states the real reason for every denial. Get on the server via your provider's web console or a working account:

$ sudo journalctl -u ssh -n 50 --no-pager    # Debian/Ubuntu
$ sudo journalctl -u sshd -n 50 --no-pager   # RHEL/CentOS/Fedora
# Or the classic log files:
$ sudo tail -50 /var/log/auth.log            # Debian/Ubuntu
$ sudo tail -50 /var/log/secure              # RHEL/CentOS/Fedora

Lines that map straight to a fix:

• Failed password for root with your correct password: root login is disabled (step 3).
• User deploy from 198.51.100.7 not allowed because not listed in AllowUsers: add the user to the AllowUsers line in sshd_config (or remove the restriction) and restart sshd.
• pam_unix(sshd:auth): authentication failure: the password really is wrong for that account.
• Failed password for invalid user: the username doesn't exist on this machine.

Step 5: Check the account's state

Still denied with the right credentials? Check whether the account can log in at all:

sudo passwd -S deploy     # "L" means locked; unlock with: sudo passwd -u deploy
sudo chage -l deploy      # look for expired password or account

Step 6: Know when it turns into a different error

fail2ban and similar tools ban your IP after a handful of Access denied responses. From that moment the symptom changes: PuTTY stops reaching the login prompt and shows Network error: Connection refused instead. If that's where you've ended up, unban yourself with the steps in PuTTY Network Error: Connection Refused, then fix whatever was failing here so you don't get re-banned.

Common edge cases