coollabsio/coolify

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

Bilge opened this issue · 7 comments

Bilge commented

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

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 commented

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 commented

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.

if ($server->isNonRoot() && ! $no_sudo) {
$command = parseCommandsByLineForSudo(collect($command), $server);
}

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

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

(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 commented

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.

! str(trim($line))->startsWith([
'cd',
'command',
'echo',
'true',
'if',
'fi',
])

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.

Bilge commented

Yes, but the purpose of this issue is to support non-sudo access.

Bilge commented

I managed to get this working, but it required custom directory permissions. Whereas the documentation calls for setting 9999:root with 0700 permissions, I had to go with localuser:localuser 0770 for every directory except for /ssh. This makes most things work, but some things are buggy, such as proxy restart not working (you have to switch to no proxy and then back to Caddy to restart it). Maybe that bug exists anyway, I don't really know whether bugs I find are due to my unconventional setup or not any more.

Of course, this is given that localuser has sudo access, but the point of this issue is to support a non-root user without any kind of root access anyway.