I launched a Debian 13 t3.micro instance on July 1, 2026, and initially connected successfully with MobaXterm and PuTTY. I later changed SSH from port 22 to port 4545 and added the corresponding inbound security-group rule. Everything worked until recently, when both clients began reporting: "Server refused our key. No supported authentication methods available (server sent: publickey)." The instance is reachable on port 4545, but authentication fails. The cloud console's browser-based instance connection also cannot connect. I have not intentionally changed or replaced the private key. The instance is idle, and I recently pointed a temporary domain's A records at its public IP. I also use Nginx and recently ran chown -R www-data:www-data on one directory under /var/www. The SSH debug output shows that the connection and key exchange succeed, but the client ultimately returns Permission denied (publickey) while trying to log in as admin. What could cause this, and what is the safest way to regain access?
5 Answers
Something on the instance may have changed the account's SSH configuration: authorized_keys, its ownership or permissions, the account shell, sshd_config, or a PAM rule. Changing DNS records cannot cause this, and chowning files under /var/www should not affect SSH unless the command accidentally included a home directory or changed broader permissions. If the root filesystem is full, or if sshd's configuration was edited, that can also cause trouble. Use the instance console, system log, or serial console if available to look for sshd authentication messages.
Try the built-in management session instead of SSH, if the instance has the management agent installed and an instance role with the required management policy. From there, inspect the authentication logs, the user's ~/.ssh/authorized_keys, permissions on the home directory and .ssh files, disk usage, firewall rules, and sshd's effective configuration. A reboot can help if the system is stuck, but it will not repair a missing key or incorrect permissions.
A management session is also useful long term because it avoids exposing SSH and gives you a recovery path when key authentication breaks.
Stopping and starting an instance without an Elastic IP can change its public IPv4 address, but that would normally produce a connection or host-key issue, not a public-key authentication failure. Confirm the current address anyway, and connect directly to the IP while troubleshooting rather than through DNS. Since the log reaches the SSH authentication stage, security-group rules and the domain's A record are unlikely to be the root cause.
The custom port is probably not the issue. Your debug log shows that TCP connection, SSH negotiation, and host-key verification all succeed on port 4545. The failure happens afterward, during public-key authentication. Check the username first: Debian images commonly use the account created by the image or cloud-init, and the correct login may not be admin. Also verify that the client is actually loading the intended private key. The lines showing the key as type -1 are worth investigating; try explicitly specifying it with OpenSSH and confirm that the file is a valid private key. PuTTY and OpenSSH can also require different key formats.
The image uses admin, and I also tried the other common account names. The same key file worked previously, but I will verify that each client is using the correct format and file.
If management access is unavailable, preserve the instance first by taking a snapshot of its root volume. Then stop the instance, detach the root volume, and attach it to a temporary recovery instance. Mount it there and inspect or repair the affected user's authorized_keys, ownership, permissions, sshd_config, logs, and disk space. Reattach the volume to the original instance afterward, or copy the required data to a replacement instance. Do not terminate the original until you have a verified backup.
This is safer than immediately deleting and recreating the server, especially if the problem is only a damaged authorized_keys file or an incorrect permission on the home directory.
The web files are under /var/www, so the recursive ownership change should be unrelated unless the command was run against a wider path than intended.