Why Debian 13 cloud images disallow SSH password auth by default — and how to enable it (via NoVNC as root)

Cloud images of Debian (and many other Linux distributions) are typically configured to use SSH key authentication only and disable password-based SSH authentication by default. This reduces the risk of remote brute-force or credential-guessing attacks and makes images safer for automated deployments where SSH keys are provisioned by the cloud platform.

If you must enable password authentication (for example, to support a specific workflow or temporary troubleshooting), below is a careful, step-by-step tutorial showing how to do it from the NoVNC console as root. I’ll include safe checks, a rollback plan, and security recommendations you should follow after making the change.

⚠️ Security warning: enabling password authentication increases your exposure to brute-force attacks. Prefer SSH keys whenever possible. If you enable passwords, lock down access immediately (strong passwords, firewall, fail2ban, allow-list IPs, or temporary enablement only).

What you’ll do (short overview)

Open your instance’s NoVNC web console and get a root shell.
Back up the SSH server configuration.
Edit /etc/ssh/sshd_config to allow password authentication (and — only if you explicitly want it — root password login).
Validate the SSH configuration.
Restart the SSH service.
Test from another client and harden the instance.

Step-by-step

1) Open NoVNC console and get a root shell

Open the web console (NoVNC) and connect to the VM. This is located in your server management page.
If the console drops you to a non-root user, become root:

# If you can sudo:
sudo -i
# or:
sudo su -

If the console already gives you a root login, you’re ready.

2) Back up the current sshd_config

Always make a backup before editing.

cp -av /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F-%T)

This creates a timestamped backup you can restore quickly.

3) Edit /etc/ssh/sshd_config to enable password auth

You can use nano, vi, or sed. I’ll show both a safe manual edit and a direct (idempotent) sed approach.

Manual edit (recommended if you’re comfortable):

nano /etc/ssh/sshd_config

Find and set (or add) these directives:

# Allow password authentication
PasswordAuthentication yes

# Make sure ChallengeResponseAuthentication is disabled (unless you use PAM 2FA)
ChallengeResponseAuthentication no

# If you want to allow root to login with a password (risky), set:
PermitRootLogin yes
# Otherwise keep PermitRootLogin prohibit-password or prohibit without-password

Save and exit (Ctrl+O, Enter, Ctrl+X in nano).

Non-interactive (sed) method — idempotent edits:

# Ensure PasswordAuthentication yes
sed -i.orig -E 's/^\s*#?\s*PasswordAuthentication\s+.*/PasswordAuthentication yes/' /etc/ssh/sshd_config || echo "PasswordAuthentication yes" >> /etc/ssh/sshd_config

# Ensure ChallengeResponseAuthentication no
sed -i.orig -E 's/^\s*#?\s*ChallengeResponseAuthentication\s+.*/ChallengeResponseAuthentication no/' /etc/ssh/sshd_config || echo "ChallengeResponseAuthentication no" >> /etc/ssh/sshd_config

# OPTIONAL: to permit root login via password (only if you really want this)
sed -i.orig -E 's/^\s*#?\s*PermitRootLogin\s+.*/PermitRootLogin yes/' /etc/ssh/sshd_config || echo "PermitRootLogin yes" >> /etc/ssh/sshd_config

Notes:

The sed commands create a .orig copy and either replace an existing line or (because of the || echo) append the directive if none was present.
Only set PermitRootLogin yes if you understand the risk. Otherwise leave it as prohibit-password or without-password to allow root only with keys.

4) Confirm the root account has a password (if you intend to use root via password)

If you’re enabling password auth for root, you must set a root password (or ensure one exists):

passwd root

Follow the prompts and choose a very strong password. If you don’t want root password login, do NOT set this — instead use sudo with a non-root user.

5) Validate the SSH config for syntax errors

Before restarting, test the config:

sshd -t

No output means the syntax is OK.
If there are errors, sshd -t will print them — fix the issues or restore the backup.

If sshd -t fails and you need to rollback:

cp -av /etc/ssh/sshd_config.bak-YYYY-MM-DD-HH:MM:SS /etc/ssh/sshd_config
# then test again
sshd -t

6) Restart the SSH service

On Debian, the service is typically called ssh.

systemctl restart ssh
systemctl status ssh --no-pager

systemctl status will show whether the service started cleanly.

7) Test from a separate client (very important)

From your local machine (not the NoVNC console), attempt to SSH in to confirm password auth works:

ssh [email protected]
# or, if testing root login (not recommended):
ssh [email protected]

Important: test from another session before closing your NoVNC console — if you lose SSH connectivity you can still recover using the NoVNC console.

If the test fails, check /var/log/auth.log and systemctl status ssh on the VM for hints.

Post-change hardening (strongly recommended)

If you must enable password auth for any reason, reduce risk immediately:

Use strong passwords (long passphrases).
Limit access by IP (cloud provider security groups / firewall, or sshd_config AllowUsers user@IP).
Install and configure fail2ban (blocks repeated failed logins).
```
apt update && apt install -y fail2ban
```
Keep root login disabled if possible: prefer PermitRootLogin prohibit-password and use sudo.
Consider enabling 2FA (e.g., Google Authenticator / PAM) for SSH.
Use key auth as primary — switch back when possible.

How to revert (quick)

If you need to quickly undo the change:

# restore backup (use the exact backup filename you created)
cp -av /etc/ssh/sshd_config.bak-2025-10-15-12:34:56 /etc/ssh/sshd_config

# test and restart
sshd -t && systemctl restart ssh

(Adjust the backup filename to whatever you see under /etc/ssh/.)

Troubleshooting tips

sshd -t — checks syntax.
systemctl status ssh — service logs.
journalctl -u ssh -n 200 --no-pager — recent SSH logs.
/var/log/auth.log — login/authentication attempts and errors.