[Bug]: Connecting to localhost as non-root user without sudo does not work

[Bilge]

Error Message and Logs

Trying to use the private key for the non-root user shows:

This key is not valid for this server.

I have manually verified this key works by running ssh coolify@host.docker.internal -i storage/app/ssh/keys/ssh_key\@joksc0kww4wkoskkogssswo4, from within Coolify's container, and the connection back to the host succeeds.

Steps to Reproduce

1. Provision user coolify with a new key and add the public key to authorized keys.
2. Log into the web interface and skip onboarding because it will always fail.
3. Add the private key in the admin interface.
4. In general configuration for the server, change the user from root -> coolify. (it will not validate yet: Error: No query results for model [App\Models\PrivateKey] 0)
5. Go to private key tab and choose the private key we added earlier.

This key is not valid for this server.

I have no idea how it thinks the key isn't valid, but it is because I tested it myself with SSH. It's also weird that the user and the key are on different settings pages, because the user and key must belong together.

Example Repository URL

No response

Coolify Version

v4.0.0-beta.367

Are you using Coolify Cloud?

No (self-hosted)

Operating System and Version (self-hosted)

Ubuntu 22.04.3 LTS

Additional Information

No response

[LaurenceJJones]

I have no idea how it thinks the key isn't valid, but it is because I tested it myself with SSH. It's also weird that the user and the key are on different settings pages, because the user and key must belong together.

Have you ensure that the public key is added to /home/coolify/.ssh/authorized_keys file?

Edit: I did see you did state you did, just double checking as users are prone to running echo X >> ~/.ssh/authorized_keys and they didnt know ~ is an alias for the current user home directory.

[Bilge]

Not only did I state that it was added, but I also stated (twice) that it was tested using ssh.

cat ~coolify/.ssh/authorized_keys

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJr9ikk6H43lE/Dpnn4vCA6bgvA59gWoKG/AJW8H/ciY coolify

[Bilge]

As best I can tell, this error occurs because Coolify expects that if the user is non-root, it will have unfettered and password-less rights to use sudo whenever it wishes. The whole point of not giving Coolify root access is so that it doesn't run (anything) as root.

https://github.com/coollabsio/coolify/blob/6987e83912baa9739faa86d43af659ec133c7029/bootstrap/helpers/remoteProcess.php#L77-L79

In this particular case, it is just trying to run ls /, so it clearly doesn't need root.

https://github.com/coollabsio/coolify/blob/6987e83912baa9739faa86d43af659ec133c7029/app/Models/Server.php#L1064

(Aside, since this is just a connectivity test, running true would probably be cleaner than attempting a directory listing.)

I still don't understand why Coolify thinks it needs root access for anything. I've added it to the docker group, giving it full access to Docker (which is almost as bad), but it should not need anything more. Correct me if I'm wrong.

[Bilge]

The following patch will make Coolify accept the private key.

- instant_remote_process(['ls /'], $this);
+ instant_remote_process(['true'], $this);

This is a bit obscure, but the reason this works is because it implicitly disables prefixing sudo, because true just happens to be in the exclusions list for automatically prefixing sudo.

https://github.com/coollabsio/coolify/blob/6987e83912baa9739faa86d43af659ec133c7029/bootstrap/helpers/shared.php#L1225-L1232

Of course, whilst this does allow you to use a valid and working private key, it is a short-sighted "solution", because everything else is still broken as everything else still (falsely) presumes to wrap everything in sudo.