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.
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_keysinside the QEMU VM.Reproduction
Tested with
vastai/kvm:ubuntu_cli_22.04-2025-11-21andvastai/kvm:cuda-12.8.1-autoon 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)
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 noin 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 defaultStrictModes yes. The key injection into the VM disk image apparently creates/root/.ssh/authorized_keyswith incorrect ownership or permissions.The
docker createlogs confirmSSH_PUBLIC_KEYis correctly passed as an env var — the issue is in the KVM launch script that writes it into the VM.