[Bug]: Connecting to localhost as non-root user without sudo does not work
Bilge opened this issue · 7 comments
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
- Provision user
coolify
with a new key and add the public key to authorized keys. - Log into the web interface and skip onboarding because it will always fail.
- Add the private key in the admin interface.
- 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
) - 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.
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
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.
coolify/bootstrap/helpers/remoteProcess.php
Lines 77 to 79 in 6987e83
In this particular case, it is just trying to run ls /
, so it clearly doesn't need root.
Line 1064 in 6987e83
(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.
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
.
coolify/bootstrap/helpers/shared.php
Lines 1225 to 1232 in 6987e83
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
.
Have you added this line to your sudoers file: https://coolify.io/docs/knowledge-base/server/non-root-user/#sudo-permissions
Yes, but the purpose of this issue is to support non-sudo access.
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.