DigitalOcean Ubuntu Droplet登录异常：SSH公钥认证失败及控制台登录问题

Hey Corey, sorry to hear you're stuck with this frustrating login roadblock on your DigitalOcean Droplet—let’s walk through practical fixes step by step to get you back in control.

First: Fix Console Login Failures #

If resetting the root password didn’t let you log in via the DigitalOcean console, start here:

• Double-check password input: The console doesn’t show any characters (not even asterisks) when you type your password. Don’t assume it’s not registering—slowly enter the exact reset password, paying attention to case and special characters.
• Wait for password propagation: Sometimes password resets take 1-2 minutes to fully apply, especially if the Droplet is under heavy load. Give it a moment before retrying.
• Verify Droplet health: Head to your DigitalOcean dashboard to confirm the Droplet is running normally. If CPU/memory is maxed out, the system might be too unresponsive to handle login requests—you may need to restart the Droplet from the dashboard first.

Next: Resolve SSH "Permission denied (publickey)" #

Once you can access the console (or use Recovery Mode if console still fails), tackle the SSH issue:

1. Audit SSH Daemon Configuration #

Edit the SSH config file with nano /etc/ssh/sshd_config and verify these critical settings:

• PasswordAuthentication: Set to yes temporarily if you want to use password login (you can switch back to no once keys are fixed).
• PubkeyAuthentication: Must be yes if you plan to use SSH keys.
• PermitRootLogin: If it’s set to prohibit-password, root can only use key login—change to yes if you need to test root password login (revert later for security).

Save changes and restart SSH:

systemctl restart sshd
# Or use this for older systems:
service ssh restart

2. Fix Key File Permissions #

SSH rejects keys if permissions are too open. For the root user (or your non-root user), run these commands:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys

Double-check that your local public key is present in /root/.ssh/authorized_keys—no accidental deletions or typos here matter.

3. Check Non-Root User Access #

If you previously used a non-root user:

• Verify their ~/.ssh/authorized_keys has the correct permissions (same as above).
• Ensure their entry in /etc/passwd isn’t corrupted (it should end with a valid shell like /bin/bash).

If Console Still Won’t Work: Use Recovery Mode #

DigitalOcean’s Recovery Mode lets you access your Droplet’s filesystem directly:

1. Power off the Droplet from the dashboard, then enable Recovery Mode and power it back on.
2. Connect via the console, follow prompts to mount your Droplet’s main partition (usually /dev/vda1 to /mnt).
3. Navigate to /mnt/etc/ssh to edit sshd_config, or check /mnt/root/.ssh/authorized_keys to fix key issues.
4. Unmount the partition and restart the Droplet in normal mode.

Extra Checks for Sudden Failures #

Since this worked yesterday, rule out these edge cases:

• System tampering: Check auth logs with cat /var/log/auth.log (or /var/log/secure on RHEL-based systems) for unusual login attempts or configuration changes.
• Local SSH cache: Clear old host entries on your local machine with ssh-keygen -R 162.243.123.123, then retry the SSH connection.

Let me know if any of these steps get you back in, or if you hit other snags—I’m happy to dig deeper with you.

内容的提问来源于stack exchange，提问作者Corey