Multi-user server with nginx authentication #236

Nottt · 2019-08-29T09:43:22Z

My goal is to have a multi-user server where users can login with their own username and passwords, and only have access to the scripts I allow them.

I have setup script-server behind a nginx docker, the only way to reach the script-server is via the nginx proxy, and the only public ports in my server are 80 and 443.

I created a htpasswd for my user, up to here everything is fine. But there are 2 issues:

I need to put my internal docker IP in trusted IPs, and it's not really static, while this could be fixed, it would be better if trusted IPs allowed to set a range... like 172.18.0.0/24

Biggest issue is all I see as identified as user is this:

2019-08-29 09:06:37,481 [identification.INFO] Assigned user_id=IP-46a12c6f2ff7496e to {'proxied_ip': 'IP', 'proxied_hostname': 'c95000b4.redacted.com.br', 'ip': '172.18.0.2', 'hostname': 'nginx-proxy.cloudbox'}

Obviously none of my users will have static IPs so this won't work! Am I missing something here?

The text was updated successfully, but these errors were encountered:

bugy · 2019-08-29T09:48:57Z

Hi @Nottt, if you want to use authentication of nginx, you would need to use this feature: #219

So, in the Script server config file, you would need to put smth like:

{
  ...
  "access": {
    "user_header_name": "X-Auth-Name"
  }
}

Where X-Auth-Name stands for the username header, sent by the proxy

Also, please note, that it works only on dev version (wasn't yet released to a stable version)

Nottt · 2019-08-29T09:51:18Z

I still don't understand. I'm not very good with nginx...

What do you mean sent by the proxy? How the proxy is going to know who is who?

You are assuming I can somehow know that IP Y is person X. I don't see hows that possible

bugy · 2019-08-29T09:58:14Z

Hi @Nottt,
you wrote:

I created a htpasswd for my user, up to here everything is fine. But there are 2 issues:
So I assumed, you configured this file in nginx proxy, or?

Nottt · 2019-08-29T10:05:51Z

I use jwilder/nginx-proxy, so it handles most of the stuff automatically, but I did create a htpasswd in my host, that gets mapped to somewhere inside the container and does what a htpasswd file does.

bugy · 2019-08-29T10:44:06Z

But do users see authentication window, when they try to connect? Nottt <[email protected]> schrieb am Do., 29. Aug. 2019, 12:05:

…

I use jwilder/nginx-proxy, so it handles most of the stuff automatically, but I did create a htpasswd in my host, that gets mapped to somewhere inside the container and does what a htpasswd file does. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236?email_source=notifications&email_token=AAJXPJI2BXNU6DN2LQVK37LQG6NP7A5CNFSM4ISADZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5N64VY#issuecomment-526118487>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJXPJJZCKMXIOC7T3SNXWTQG6NP7ANCNFSM4ISADZCQ> .

Nottt · 2019-08-29T10:45:48Z

Yes...

bugy · 2019-08-29T10:53:12Z

Could you try to add the following setting to nginx proxy_set_header X-Forwarded-User $remote_user And then use X-Forwarded-User for the script server config PS I'm not nginx proxy expert, this advice was taken from stack overflow :) And i would be able to check it only in several hours Nottt <[email protected]> schrieb am Do., 29. Aug. 2019, 12:45:

…

Yes... [image: image] <https://user-images.githubusercontent.com/13532436/63934117-ffc74080-ca30-11e9-92f5-68a1eba1bc66.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236?email_source=notifications&email_token=AAJXPJIPZRE3EBN4ONAL5FLQG6SFZA5CNFSM4ISADZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5OCDMA#issuecomment-526131632>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJXPJOFEXOSFV2PRLTSOSTQG6SFZANCNFSM4ISADZCQ> .

Nottt · 2019-08-30T01:27:44Z

OK I haven't been able to test this yet, but I already found another issue.

When I enabled cloudflare, everyone lost access. I do plan on having cloudflare after my nginx-docker to hide my server IP.

What needs to be changed to accomplish this together with what you said?

That's why relying on IPs is the worst method possible for authentication, who was static and immutable IPs nowadays?

LDAP is cool and all, but sometimes the basic is all we need

bugy · 2019-08-30T04:35:08Z

Hi Nott, to be honest i don't know how cloudflare works and don't aware of any issues with it. May be you can check logs in a browser and also a network tab there. Nottt <[email protected]> schrieb am Fr., 30. Aug. 2019, 03:27:

…

OK I haven't been able to test this yet, but I already found another issue. When I enabled cloudflare, everyone lost access. I do plan on having cloudflare after my nginx-docker to hide my server IP. What needs to be changed to accomplish this together with what you said? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#236?email_source=notifications&email_token=AAJXPJOHI47VDSDIW6WYAXDQHBZRFA5CNFSM4ISADZC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5QIKYI#issuecomment-526419297>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJXPJKDPRH26AOEOPPM7U3QHBZRFANCNFSM4ISADZCQ> .

bugy · 2019-08-30T20:23:25Z

Hi @Nottt,

so, I checked nginx locally, and with these settings, basic auth works on nginx and X-Forwarded-User header is correctly filled with a username:

                auth_basic           "Script server auth";
                auth_basic_user_file /etc/apache2/.htpasswd;
                proxy_set_header X-Forwarded-User $remote_user;

That's why relying on IPs is the worst method possible for authentication, who was static and immutable IPs nowadays?

I can perfectly agree with it. IP is just a default setting if people don't want or don't need anything more advanced (for example, my scripts at work are not doing anything dangerous and anyone can run them).

When I enabled cloudflare, everyone lost access

Do you mean they cannot access the server, because their IPs are not whitelisted? Or there is some different error?

Nottt · 2019-09-02T05:59:08Z

Update

The correct header to forward according to #219 is:

proxy_set_header X-Auth-Name $remote_user;

Thanks :)

Ok, so I changed my docker to bugy/script-server:dev and added this to my nginx:

auth_basic           "Script server auth";
auth_basic_user_file /etc/nginx/htpasswd/scripts.domain.com;
proxy_set_header X-Forwarded-User $remote_user;

And my configuration file look like this:

{
   "port":5000,
   "address":"0.0.0.0",
   "title":"Title",
   "access":{
      "allowed_users":[
         "admin",
         "user"
      ],
      "admin_users":[
         "admin"
      ],
      "user_header_name":"X-Auth-Name",
      "trusted_ips":[
         "172.18.0.2"
      ],
      "logging":{
         "execution_file":"$DATE-$ID.log",
         "execution_date_format":"%y-%m-%d_%H-%M"
      }
   }
}

But after bypassing the login page, I get a 403 forbidden from the script server unless I allow my internal docker IP on the allowed users.

2019-09-02 05:52:32,060 [web_server.WARNING] User 172.18.0.2 is not allowed

I think the nginx thing is working, because when looking at my nginx-docker logs I see the username of the logged in user after the IPs like this

nginx.1    | scripts.domain.com *IP* - user [02/Sep/2019:05:43:54 +0000] "GET /b789b6e0d14b9092f8e9468ccd3e3217.png HTTP/2.0" 200 1353 "https://scripts.domain.com/index.html" "Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36"

If I allow my docker IP, I can access the page but can't see the scripts I locked to that user only

Interestingly this is the output of https://scripts.domain.com/auth/info is:

{"enabled": false, "username": null, "admin": false}

Any ideas?

bugy · 2019-09-02T06:11:09Z

Hi @Nottt, in the script server config please use X-Forwarded-User (as in nginx) instead of X-Auth-Name

Nottt · 2019-09-02T06:13:58Z

I just edited it to say I found the cause of the issue...thanks for the support!

This would be handy in the wiki btw.

Just noticed there's a , missing after "title": "My Script Server" in the server configuration example

Nottt · 2019-09-02T06:26:44Z

After enabling cloudflare, the script-server breaks.... at the logs I see:

2019-09-02 06:24:22,596 [tornado.general.DEBUG] Can "Upgrade" only to "WebSocket".

I tried to google, but it seems to be a tornado thing... It'd be nice if we could run cloudflare to hide the server IP :/

bugy · 2019-09-02T07:19:49Z

Hi @Nottt, seems that websocket connections are not forwarded properly.
Here https://community.cloudflare.com/t/can-i-use-cloudflare-with-websockets/104035/2
they suggest to check if websockets are enabled. Could you check it please?

Also, to double-check: you left your nginx configuration untouched, right? And it was working without any issues before?
There was a similar issue with nginx for another user: #110 (comment)

Nottt · 2019-09-02T07:21:40Z

Actually this doesn't seem to be related to cloudflare, but something else. I can't load/execute any script after doing this changes and disabling cloudflare.

I was only testing for access, so I didn't notice before that running the scripts was broken.

I'm still investigating what could be causing it

bugy · 2019-09-02T07:23:15Z

Please make sure, that the following parameters are in your nginx configuration:

	# needed for websockets
	proxy_http_version 1.1;
	proxy_set_header Upgrade $http_upgrade;
	proxy_set_header Connection "upgrade";
	proxy_set_header Origin http://$proxy_host;

(as per https://github.com/bugy/script-server/wiki/Reverse-Proxy-setup#nginx)

Nottt · 2019-09-02T07:35:03Z

Ok this stopped that error, but now for all scripts that I locked to a specific user, can't be accessed: Access to the script is denied

{
   "name":"Name",
   "script_path":"scripts/user-771313.sh",
   "description":"Description",
   "allowed_users":[
      "771313"
   ],
   "parameters":[
      {
         "name":"User",
         "type":"text",
         "required":true
      }
   ]
}

This is my templates, I made sure there is one for each user, I only changed the allowed user and the script path, they are 777...

Could it be because the name and description is the same for every .json? This script is equal to everyone, it just uses a different default for each user...

bugy · 2019-09-02T07:37:26Z

Hi @Nottt, the names should be unique

Nottt · 2019-09-02T07:41:28Z

Ok just renaming the name of the task to Name 771313 and etc worked.

But that's not ideal, the name of the script/task is the same for everyone, since they do the same thing, just using different variables for each user.

The UI gets a little weird, but at least it works! Thanks

bugy added the question label Aug 29, 2019

bugy added the resolved label Dec 26, 2019

bugy closed this as completed Dec 26, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Multi-user server with nginx authentication #236

Multi-user server with nginx authentication #236

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 •

edited

Loading

Nottt commented Aug 29, 2019 •

edited

Loading

bugy commented Aug 29, 2019

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 via email

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 via email

Nottt commented Aug 30, 2019 •

edited

Loading

bugy commented Aug 30, 2019 via email

bugy commented Aug 30, 2019 •

edited

Loading

Nottt commented Sep 2, 2019 •

edited

Loading

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019 •

edited

Loading

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

Multi-user server with nginx authentication #236

Multi-user server with nginx authentication #236

Comments

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 • edited Loading

Nottt commented Aug 29, 2019 • edited Loading

bugy commented Aug 29, 2019

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 via email

Nottt commented Aug 29, 2019

bugy commented Aug 29, 2019 via email

Nottt commented Aug 30, 2019 • edited Loading

bugy commented Aug 30, 2019 via email

bugy commented Aug 30, 2019 • edited Loading

Nottt commented Sep 2, 2019 • edited Loading

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019 • edited Loading

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

bugy commented Sep 2, 2019

Nottt commented Sep 2, 2019

bugy commented Aug 29, 2019 •

edited

Loading

Nottt commented Aug 29, 2019 •

edited

Loading

Nottt commented Aug 30, 2019 •

edited

Loading

bugy commented Aug 30, 2019 •

edited

Loading

Nottt commented Sep 2, 2019 •

edited

Loading

Nottt commented Sep 2, 2019 •

edited

Loading