docker login failed via https reverse proxy

rhessinger

What about your docker daemon.json? By default, docker will use https, unless if the host is listed within the insecure-registries in your docker daemon.json. Can you please verify that URL does not exist in that list?

Thanks,
Rich

viceice

@viceice said in docker login failed via https reverse proxy:

www-authenticate: Bearer realm="http://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu"

docker login proget-test.kriese.eu make a get request to http://proget-test.kriese.eu/v2/ which return the header www-authenticate: Bearer realm="http://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu.
Then docker is maoking a reuest to http://proget-test.kriese.eu/v2/_auth as told in the response, which fails, because protokoll changed from https to http.

The proget auth header should be like:
www-authenticate: Bearer realm="https://proget-test.kriese.eu/v2/_auth",service="proget-test.kriese.eu

The http://proget-test.kriese.eu/v2/_auth is not available, as i do not forward these insecure http requests from proxy to proget

for reference my daemon.json

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false
}

pretty default config

rhessinger

Hi @viceice,

This is very weird to me. When you call docker login, you said it is initially doing a get to http://proget-test.kriese.eu/v2/ not https://proget-test.kriese.eu/v2/. This means that there is something configured in your docker client to not use https in docker requests. The reason ProGet is returning an http:// based realm is because the initial request is being made non-https URL.

Can you send a screenshot of your command output in the docker login process?

Thanks,
Rich

viceice

Hi @rhessinger,

Sorry my bad, it's a typo, first request is going to https://proget-test.kriese.eu/v2/ and second is going to http://proget-test.kriese.eu/v2/_auth

The second request is expected by docker to go to http because of the wrong www-authenticate header

atripp

Hi @viceice

The http://proget-test.kriese.eu/ being returned as the Realm because it's set as the BaseUrl.

If you remove that, then it will work; however, it would cause your instance of ProGet Free to report licensing errors due to your reverse proxy configuration.

Ultimately this is a reverse proxy issue, and we might be able to have the Relm respect the X-Forward* headers.... however, I'm not sure if that's appropriate / okay to do?

It might be a security problem? Can you find any documentation or discussion on this topic?

The code change is easy, but we want to confirm it's okay to make before considering it further.

Cheers,
Alana

viceice

Hi @atripp

My BaseUrl is empty, so proget is correctly assuming the hostname from headers.
But as you said, it isn't respecting the X-Forward* headers.
That why proget falsy returns a http url, because the reverse proxy is doing http to proget.

If i add the baseUrl, i'll get licensing issues for a nuget v3 loopback connector, so i was told to empty baseUrl. see https://forums.inedo.com/topic/3037/how-to-configure-the-proget-free-with-self-connector/13

So my assumption would be, that proget will respect the X-Forward* headers as already doing in other feeds.

Another options would be, if we can configure proget to listen on https with a provided tls certificate, so i would have end-to-end tls encryption.

rhessinger

Hi @viceice,

Looking back at your other forums post. The last fix we released should allow you to set the Web.BaseUrl and with the addition of X-Forward* headers in your reverse proxy, it should not give you those license errors any more? Were you able to verify that it still does give oyu the licenses errors?

Thanks,
Rich

viceice

ok, setting BaseUrl fixes the docker login but causes new license violations

I now have 2 feeds a and b and configured a loopback connector on a to feed b

Errors / Warnings:

The visualon.test test nuget packages was added to feed b

btw: license issues are only go away, if i configure a diffrent license key. If i simply try to update existing key, license violations aren't removed. So the docu is wrong.

I think the solution would be that the licensing code checks passed request url against the configured baseUrl and ignore those requests.

rhessinger

Hi @viceice,

Thanks for testing this for me. I think I may see your issue. When the Web.BaseUrl is set to https://proget-test.kriese.eu, the connector should use the URL https://proget-test.kriese.eu/nuget/b/v3/inedx.json. If you set it up that way, do you still get the license violations?

I'll look into the license key issue. It should work as the documentation describes it.

Thanks,
Rich

viceice

@rhessinger said in docker login failed via https reverse proxy:

Thanks for testing this for me. I think I may see your issue. When the Web.BaseUrl is set to https://proget-test.kriese.eu, the connector should use the URL https://proget-test.kriese.eu/nuget/b/v3/inedx.json. If you set it up that way, do you still get the license violations?

yes, i can use https://proget-test.kriese.eu/nuget/b/v3/index.json or http://localhost/nuget/b/v3/index.json and always get licensing issues. (baseUrl=https://proget-test.kriese.eu)

So i'll set the BaseUrl on our other proget too and get starting licensing issues, even if the connector url matches the BaseUrl.

One thing to note is, if i set the BaseUrl to https://proget-test.kriese.eu all requests from proget connector will go through the proxy. So i think this is causing the licensing issue.

atripp

@viceice said in docker login failed via https reverse proxy:

So my assumption would be, that proget will respect the X-Forward* headers as already doing in other feeds.

You're right, when writing the Basic realm="<url>" header, ProGet does not look at the X-Forward* headers. I'm not sure if we should? Would that be a security problem? It kind of seems like it might? Or maybe not? I didn't find anything about the topic discussed on the 'net after a quick search...

How about just configuring your reverse proxy to just rewrite that realm in the auth header to go from http to https? I suspect, thatw ould help.

If you can do that, and then we can update the docs on how to do it, other Free users would be very much appreciative :)

viceice

As for the security concern: maybe add an environment config option to pass trusted proxy ips like traefik supports forwardedHeaders.trustedIPs

Maybe another option is to use the ASP.NET Core proxy config options to solve the issue.

Ok, my reverse proxy isn't able to rewrite headers traefik/traefik#6047

So i will go with setting BaseUrl and hope that the licensing issues get fixed in a later version.
I only see the issues when using an admin user, which we normally not use.
I also hope you won't block this usage scenario in a future version whithout a proper solution.

rhessinger

Hi @viceice,

I did a few searches and have you tried setting the hostsProxyHeaders> Maybe something like this: traefik.frontend.headers.hostsProxyHeaders=www-authenticate? The docs make it sound like it will look in those headers for URLs that are proxied. You could give that a shot.

Thanks,
Rich