Bug: Hardcoded SSH User in runpodctl Prevents Support for Non-Root Users

[andylizf]

Description:

In the runpodctl codebase, the SSH client configuration is hardcoded to use the root user:

runpodctl/cmd/project/ssh.go

Lines 293 to 298 in b508558

	config := &ssh.ClientConfig{
	User: "root",
	Auth: []ssh.AuthMethod{
	ssh.PublicKeys(privateKey),
	},
	HostKeyCallback: ssh.InsecureIgnoreHostKey(),

This approach causes issues when dealing with Docker images or environments that are configured to run as a non-root user by default. SSH attempts will fail with permission errors when the container does not allow root access.

Proposed Fix:

Instead of hardcoding the User: "root", it would be better to dynamically retrieving the default user from the API if available This change would improve flexibility and compatibility with a wider range of container setups.

Related Issue:

This problem is also related to runpod/runpod-python#399. Integrating such an API with runpodctl would allow for dynamic SSH user configuration, resolving the non-root user problem seamlessly.

[TimPietruskyRunPod]

@cxmplex Thanks for raising this. We looked into it — the core problem is that the Runpod API doesn't expose which user a container runs as, and there's no reliable way to determine this from the outside without pulling and inspecting the Docker image (which we don't do for cost and privacy reasons).

The CLI currently hardcodes root@ in the SSH command because that's the default for all Runpod pods:

ssh -i ~/.runpod/ssh/RunPod-Key-Go root@149.36.1.202 -p 16444

Question for you: Would adding a --user flag to ssh info help your use case? Something like:

runpodctl ssh info <pod-id> --user ubuntu
# → ssh -i ... ubuntu@149.36.1.202 -p 16444

It would default to root but let tools like SkyPilot override it when they know the image uses a non-root user. Or does SkyPilot need the user to be auto-detected from the API (which would require a platform-level change, not just the CLI)?