-
Notifications
You must be signed in to change notification settings - Fork 79
Description
SSH to any KVM VM instance fails with Permission denied (publickey). Instance logs reveal sshd rejects the key due to incorrect file permissions on /root/.ssh/authorized_keys inside the QEMU VM.
Reproduction
vastai create instance <ID> --image "vastai/kvm:@vastai-automatic-tag" --ssh --direct --disk 40
# wait for "running" status
ssh -p <port> root@<ip>
# → Permission denied (publickey).Tested with vastai/kvm:ubuntu_cli_22.04-2025-11-21 and vastai/kvm:cuda-12.8.1-auto on multiple machines (South Korea, China), via both direct and proxy SSH. Same result every time. Docker (non-KVM) instances work fine with the same key.
Instance logs (sshd)
Authentication refused: bad ownership or modes for file /root/.ssh/authorized_keys
Failed publickey for root from <CLIENT_IP> port 55282 ssh2: ED25519 SHA256:<KEY_FINGERPRINT>
The key fingerprint matches the account key exactly — sshd sees the correct key but refuses to check it because the file modes are wrong.
Analysis
The container's Dockerfile (Step 6/8) sets StrictModes no in sshd_config, but that only affects the outer container's sshd. KVM instances run a QEMU VM inside the container, and the VM's sshd has the default StrictModes yes. The key injection into the VM disk image apparently creates /root/.ssh/authorized_keys with incorrect ownership or permissions.
The docker create logs confirm SSH_PUBLIC_KEY is correctly passed as an env var — the issue is in the KVM launch script that writes it into the VM.