Home: dotnet.exe restore does not work with basic authentication on linux

[TheRealPiotrP]

Steps to reproduce

We have a private repo which needs authentication. I would like to build up an ubuntu build agent host. Right now it can't restore the package from our nuget repository. My nuget config looks like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="NexogenNuget" value="https://COMPANY_NUGET_URI/NugetServer/nuget" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <packageSourceCredentials>
    <NexogenNuget>
      <add key="Username" value="NUGETUSER" />
      <add key="ClearTextPassword" value="NUGETPWD" />
    </NexogenNuget>
  </packageSourceCredentials>
</configuration>

The nuget server is hosted in IIS and Windows authentication and Basic authentication are enabled. If i try it with curl i can access it with a local user or with my windows account also.

curl -u NUGETUSERNUGETPWD "https://COMPANY_NUGET_URI/NugetServer/nuget/FindPackagesById()?id='TestPkg'"

Returns

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<feed xml:base="https://COMPANY_NUGET_URI/NugetServer/nuget/" xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
  <title type="text">FindPackagesById</title>
  <id>https://COMPANY_NUGET_URI/NugetServer/nuget/FindPackagesById</id>
  <updated>2016-10-14T11:53:16Z</updated>
  <author>
    <name />
  </author>
  <link rel="self" title="FindPackagesById" href="FindPackagesById" />

Expected behavior

It should download the package from private repo. I read that clear text password is supported.

Actual behavior

But if i try the dotnet restore it says:

log  : Retrying 'FindPackagesByIdAsyncCore' for source 'https://COMPANY_NUGET_URI/NugetServer/nuget/FindPackagesById()?id='testpkg''.
log  : Response status code does not indicate success: 401 (Unauthorized).

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
Version: 1.0.0-preview2-003131
Commit SHA-1 hash: 635cf40e58

Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64

---

Moved from https://github.com/dotnet/cli/issues/4410 for @Kemyke

[rrelyea]

Can you please help @kemyke

[Kemyke]

What other info should i provide to help the investigation?
I experienced this behavior when i use the 'dotnet restore' command, so i am not sure if this is the good forum for my problem.

[joelverhagen]

@Kemyke, I tried this out on both Ubuntu and Windows and it works out for me. What's the directory structure? What is your project.json? What's your directory structure (in particular, where is the NuGet.config file in relation to your project)? Where are you executing dotnet restore?

[rrelyea]

@Kemyke - time is running out on this milestone. The sooner you can respond with details, the more likely this issue will be addressed soon. Thanks!

[Kemyke]

We have an on-premise Windows 2012 R2 server running IIS. There is a Nuget server site on it, based on this nuget (https://github.com/NuGet/NuGet.Server). The windows and basic authentications are turned on and anonymous auth is turned off.

We have an ubuntu server in Azure which we want to use as a build machine. I checked out one of our solution to build there. The project is located in the home directory of the user. (~/project)
The nuget config is in the ~/.nuget/NuGet/NuGet.config, its content is in my first post.

Solution folder looks like this:

\
  \Project1
  \Project2
  \solution.sln

When i run dotnet restore from the root of the solution they try to resolve our own nuget packages. The restore finds the project.json-s succesfully. And it uses the correct nuget file because it tries to connect to our company nuget server but the nuget servers answer is 401.
If i turn the anonymous connection on on the IIS site, everything goes well, the restore completed successfully.

[joelverhagen]

Questions:

• Would it be possible to provide some network level logging here? In particular, Wireshark with SSL
  decryption. Alternatively, you could try mitmproxy. I have not tried these steps before.
• Could you provide a minimal project that reproduces the issue?
• Does this reproduce on Windows with the same CLI version, project, and NuGet.Config setup?

I tried again on my Ubuntu machine. Here's the steps I followed:

$ pwd
/home/ddcloud/jver/repro3664

$ ls -R ~/.nuget/NuGet/
/home/ddcloud/.nuget/NuGet/:
NuGet.Config

$ ls -R .
.:
src

./src:
proj

./src/proj:
Program.cs  project.json

$ cat ~/.nuget/NuGet/NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="NexogenNuget" value="https://REDACTED.azurewebsites.net/nuget" />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
  </packageSources>
  <packageSourceCredentials>
    <NexogenNuget>
      <add key="Username" value="REDACTED" />
      <add key="ClearTextPassword" value="REDACTED" />
    </NexogenNuget>
  </packageSourceCredentials>
</configuration>

$ cat src/proj/project.json
{
  "version": "1.0.0-*",
  "buildOptions": {
    "debugType": "portable",
    "emitEntryPoint": true
  },
  "dependencies": {
    "ServiceableOldNs": "1.1.0"
  },
  "frameworks": {
    "net46": {}
  }
}

$ ~/jver/dotnet/1.0.0-preview2-003131/dotnet --info
.NET Command Line Tools (1.0.0-preview2-003131)

Product Information:
 Version:            1.0.0-preview2-003131
 Commit SHA-1 hash:  635cf40e58

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  14.04
 OS Platform: Linux
 RID:         ubuntu.14.04-x64

$ ~/jver/dotnet/1.0.0-preview2-003131/dotnet restore --verbosity information
log  : Restoring packages for /home/ddcloud/jver/repro3664/src/proj/project.json...
info :   GET https://REDACTED.azurewebsites.net/nuget/FindPackagesById()?id='ServiceableOldNs'
info :   GET https://api.nuget.org/v3-flatcontainer/serviceableoldns/index.json
info :   NotFound https://api.nuget.org/v3-flatcontainer/serviceableoldns/index.json 241ms
info :   OK https://REDACTED.azurewebsites.net/nuget/FindPackagesById()?id='ServiceableOldNs' 1148ms
info :   GET https://REDACTED.azurewebsites.net/api/v2/package/serviceableoldns/1.1.0
info :   OK https://REDACTED.azurewebsites.net/api/v2/package/serviceableoldns/1.1.0 62ms
log  : Installing ServiceableOldNs 1.1.0.
info : Committing restore...
log  : Writing lock file to disk. Path: /home/ddcloud/jver/repro3664/src/proj/project.lock.json
log  : /home/ddcloud/jver/repro3664/src/proj/project.json
log  : Restore completed in 1636ms.

NuGet Config files used:
    /home/ddcloud/.nuget/NuGet/NuGet.Config

Feeds used:
    https://REDACTED.azurewebsites.net/nuget
    https://api.nuget.org/v3/index.json

Installed:
    1 package(s) to /home/ddcloud/jver/repro3664/src/proj/project.json

[Kemyke]

It works fine from a Windows machine.
I tried with windows auth and basic auth. I can restore package from the private repo with both methods.

[joelverhagen]

@Kemyke, without some repro environment that I can access or network logs (complete HTTP sessions) I can't make a good assessment of what is going on here.

[joelverhagen]

Closing until we have a trace of network traffic or can repro it locally. Re-open if desired!

[vgheri]

Hello,

I'd like to submit new information so that the issue can be reopened.

I still have the problem of not being able to restore packages from a secured private repo.
Please find following information about dotnet version and commands executed:

OS : Mac OS X 10.12.5
Dotnet version: 1.0.4

NuGet.Config file

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageRestore>
        <!-- Allow NuGet to download missing packages -->
        <add key="enabled" value="True" />

        <!-- Automatically check for missing packages during build in Visual Studio -->
        <!--<add key="automatic" value="True" />-->
    </packageRestore>

    <packageSources>
        <clear />
        <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />
        <add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
        <add key="Nexus" value="REDACTED" />
    </packageSources>

    <packageSourceCredentials>
      <Nexus>
          <add key="Username" value="REDACTED" />
          <add key="ClearTextPassword" value="REDACTED" />
      </Nexus>
    </packageSourceCredentials>

    <apikeys>
        <add key="http://REDACTED" value="REDACTED" />
    </apikeys>
</configuration>

$> dotnet restore --configfile NuGet.Config article.csproj
Valerios-MacBook-Pro:article vgheri$ dotnet restore --configfile NuGet.Config article.csproj
  Restoring packages for /Users/vgheri/go/src/REDACTED/REDACTED/go/service/article/.sdk/dotnet/article/article.csproj...
  Retrying 'FindPackagesByIdAsyncCore' for source 'http://REDACTED/FindPackagesById()?id='REDACTED''.
  Response status code does not indicate success: 401 (Unauthorized).
  Retrying 'FindPackagesByIdAsyncCore' for source 'http://REDACTED/FindPackagesById()?id='REDACTED''.
  Response status code does not indicate success: 401 (Unauthorized).
/usr/local/share/dotnet/sdk/1.0.4/NuGet.targets(97,5): error : Failed to retrieve information about 'REDACTED' from remote source 'http://REDACTED/FindPackagesById()?id='REDACTED''. [/Users/vgheri/go/src/REDACTED/REDACTED/go/service/article/.sdk/dotnet/article/
article.csproj]

/usr/local/share/dotnet/sdk/1.0.4/NuGet.targets(97,5): error :   Response status code does not indicate success: 401 (Unauthorized). [/Users/vgheri/go/src/[REDACTED]/go/service/article/.sdk/dotnet/article/article.csproj]

I tried with both SourceCredentials and apikeys, I tried using the nuget set api key command, I tried copying the config into ~/.nuget/NuGet/NuGet.Config, with no luck.

If I manually execute the HTTP request sending a basic auth header, I get the expected response from the remote repository.
I captured TCP traffic generated by dotnet restore --configfile NuGet.Config article.csproj and I believe it shows a bug with the current implementation: the first HTTP call has no auth header at all, the second time after the client receives the 401, dotnet sends another request with a probably malformed auth header

GET /REDACTED/FindPackagesById()?id='REDACTED' HTTP/1.1
Host: REDACTED
Accept-Encoding: gzip,deflate
Accept: application/atom+xml, application/xml
user-agent: NuGet MSBuild Task/4.0.0 (Darwin 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64)
Accept-Language: en-US


HTTP/1.1 401 Unauthorized
Date: Thu, 22 Jun 2017 11:39:46 GMT
Server: Nexus/3.1.0-04 (OSS)
WWW-Authenticate: BASIC realm="Sonatype Nexus Repository Manager"
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Connection: keep-alive


GET /REDACTED/FindPackagesById()?id='REDACTED' HTTP/1.1
Host: REDACTED
Authorization: Basic Og==
Accept-Encoding: gzip,deflate
Accept: application/atom+xml, application/xml
user-agent: NuGet MSBuild Task/4.0.0 (Darwin 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64)
Accept-Language: en-US


HTTP/1.1 401 Unauthorized
Date: Thu, 22 Jun 2017 11:39:46 GMT
Server: Nexus/3.1.0-04 (OSS)
WWW-Authenticate: BASIC realm="Sonatype Nexus Repository Manager"
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Length: 0
Connection: keep-alive

CC @joelverhagen

[vgheri]

Hello, I see unfortunately the issue is still closed and my comment has probably gone unnoticed.
I think not being able to restore packages from a secured repo is a pretty big issue.
CC @joelverhagen @rrelyea

[rrelyea]

Reopening and placing in 4.4 milestone. Too late for 4.3. As such, we won't be able to give it much bandwidth for a while.

[henning-krause]

Any ideas when this will be fixed? Hitting the same issue with my on-prem TFS and a Linux agent...

[henning-krause]

I investigated a little more and put fiddler between the linux box and our TFS Server. I also captured an strace log to ensure that the correct nuget.config is read.

I have a similar nuget.conf as @piotrpMSFT and tried it both, with a PAT and username / password.

In the strace log I see that the correct nuget.config file is accessed. And indeed, if I switch the clearTextPassword to password, the "dotnet restore" command complains that encrypted passwords are not supported on Linux. So clearly, the command is reading my config file.

However, examining the requests using Fiddler, not the client does not send ANY authorization header at all.

[ekarlso]

Any reason why this isnt fixed? It makes having a private repo totally useless in our case..

[lzocateli00]

I'm signing up for this channel, I'm having the same problem to restore private Nuget server packages

[evil-shrike]

Any update?

[alexzaytsev-newsroomly]

Not sure if this is related, but i am facing this issue on Windows with .net 2.0 specifically when i restore the packages for sln, e.g. dotnet restore Bla.sln --configfile NuGet.config --verbosity Detailed gives me the 401s in the RestoreTask in NuGet.targets.

[emgarten]

I'm not able to repro this.

I tried the following with dotnet CLI 2.0.3 on Ubuntu 16.04:

1. Created a private VSTS feed
2. added a package to the feed
3. dotnet new classlib
4. manually added a package reference to the .csproj
5. added a nuget.config file to the project folder containing the VSTS feed and the credentials in clear text
6. dotnet restore
7. package was downloaded successfully from the private feed, it fails without the credentials in nuget.config

It looks like a lot of people are hitting what could be similar issues, but it is unclear why the network calls are failing, and there could be a number of reasons for that. If you are hitting this please check:

1. Verify that the failures are not caused by a proxy
2. Verify that the credentials are correct and present in cleartext in nuget.config. Also verify that nuget.config is being used and the feed is not coming from a different settings file.
3. Verify that the problem is not actually being used by the feed
4. Checking if nuget.exe with mono works for the same scenario, both the latest 4.5.0 and older 2.8.6 version would be useful to verify.

Since this was originally verified over a year ago on linux, and still does not have a repro I am going to close this issue.

As for sending the request first without credentials, this is often the expected behavior. Once the server sends a 401 response code the client will search or prompt for credentials, then re-send with the credentials entered by the user.

I will happily investigate further if someone can provide help with any of the following:

1. A private but publicly accessible feed and credentials that I can use to repro this should this issue be server specific.
2. A PR for nuget.client with a fix that solves the issue locally for your private server that I can take a look at. Or some exact guidance on where the network calls are incorrect for your feed.

[NicolasDorier]

@emgarten do not close that. Lot's of people have the issue, it is not a collective hallucination and people here took lot's of time to document what is going on... here is the repro on windows.

dotnet new nugetconfig
dotnet new classlib
dotnet pack
dotnet nuget push .\bin\Debug\*.nupkg --source "https://www.myget.org/F/metacosa/api/v2/package"
# info : Pushing 219250496.1.0.0.nupkg to 'https://www.myget.org/F/metacosa/api/v2/package'...
# info :   PUT https://www.myget.org/F/metacosa/api/v2/package/
# info :   Forbidden https://www.myget.org/F/metacosa/api/v2/package/ 1419ms

nuget setapikey "API_KEY" -Source "https://www.myget.org/F/metacosa/api/v2/package" -ConfigFile "nuget.config"

dotnet nuget push .\bin\Debug\*.nupkg --source "https://www.myget.org/F/metacosa/api/v2/package"
# info : Pushing 219250496.1.0.0.nupkg to 'https://www.myget.org/F/metacosa/api/v2/package'...
# info :   PUT https://www.myget.org/F/metacosa/api/v2/package/
# info :   Created https://www.myget.org/F/metacosa/api/v2/package/ 2275ms
# info : Your package was pushed.

mkdir OtherProj;cd OtherProj
dotnet new classlib
dotnet add package 219250496 --source "https://www.myget.org/F/metacosa/api/v2/package"

# log  : Restoring packages for C:\Users\NicolasDorier\AppData\Local\Temp\219250496\OtherProj\OtherProj.csproj...
# info :   GET https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496'
# info :   Unauthorized https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496' 1404ms
# log  : Retrying 'FindPackagesByIdAsyncCore' for source 'https://www.myget.org/F/metacosa/api/v2/package/# # FindPackagesById()?id='219250496''.
# log  : Response status code does not indicate success: 401 (Unauthorized).
# info :   GET https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496'
# info :   Unauthorized https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496' 311ms
# log  : Retrying 'FindPackagesByIdAsyncCore' for source 'https://www.myget.org/F/metacosa/api/v2/package/# # FindPackagesById()?id='219250496''.
# log  : Response status code does not indicate success: 401 (Unauthorized).
# info :   GET https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496'
# info :   Unauthorized https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496' 321ms
# error: Failed to retrieve information about '219250496' from remote source 'https://www.myget.org/F/metacosa/api/v2/package/FindPackagesById()?id='219250496''.
# error:   Response status code does not indicate success: 401 (Unauthorized).

dotnet add package 219250496 --source "https://www.myget.org/F/metacosa/api/v3/index.json"

# log  : Restoring packages for C:\Users\NicolasDorier\AppData\Local\Temp\219250496\OtherProj\OtherProj.csproj...
# error: Unable to load the service index for source https://www.myget.org/F/metacosa/api/v3/index.json.
# error:   Response status code does not indicate success: 401 (Unauthorized).

nuget setapikey "API_KEY" -Source "https://www.myget.org/F/YOUR_FEED/api/v3/index.json" -ConfigFile "..\nuget.config"

dotnet add package 219250496 --source "https://www.myget.org/F/metacosa/api/v3/index.json"

#   Writing C:\Users\NicolasDorier\AppData\Local\Temp\tmp4A7E.tmp
# info : Adding PackageReference for package '219250496' into project 'C:\Users\NicolasDorier\AppData\Local\Temp\219250496\OtherProj\OtherProj.csproj'.
# log  : Restoring packages for C:\Users\NicolasDorier\AppData\Local\Temp\219250496\OtherProj\OtherProj.csproj...
# error: Unable to load the service index for source https://www.myget.org/F/metacosa/api/v3/index.json.
# error:   Response status code does not indicate success: 401 (Unauthorized).

Try exact same step on your own private repo.
I can give you the creds to this server if you want...

Also worth noting dotnet push works but not dotnet restore.

[IRooc]

@emgarten we still have this issue just setup private nuget repository in iis with windows auth on it. Nuget works fine but dotnet restore fails! So the failing restore is done on a mac and the repo server is IIS. It is still an issue

[emgarten]

@NicolasDorier from your steps I only see the API key being set. The API key is not used to authorize when reading a feed. It is only used for push.

Double check that your NuGet.Config file contains the username and cleartext credentials for the feed, and that the credentials are valid.

[emgarten]

@IRooc windows auth support in dotnet.exe restore is tracked here: https://github.com/NuGet/Home/issues/2393

[NicolasDorier]

@emgarten thanks a lot, this was the problem. I used nuget sources add to add the nuget source with myget credentials and it worked fine.

[DarkChaos]

@emgarten Hi, I am trying to build a netcoreapp2.0 in a Docker Container on Windows 10, VS 2017 and Docker CE (17.09.0-ce-win33). I have also the same issue:

/usr/share/dotnet/sdk/2.1.4/NuGet.targets(103,5): error : Unable to load the service index for source https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/FeedName/nuget/v3/index.json. [/src/solution.sln]
/usr/share/dotnet/sdk/2.1.4/NuGet.targets(103,5): error : Response status code does not indicate success: 401 (Unauthorized). [/src/solution.sln]

To build the Container and Solution i use the following dockerfile:

FROM microsoft/aspnetcore:2.0 AS base
WORKDIR /app
EXPOSE 80

FROM domain/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY *.sln ./
COPY src/solution/solution.csproj src/solution/src/solution/
RUN dotnet restore
COPY . .
WORKDIR /src/src/solution
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "solution.dll"]

For the domain/aspnetcore-build:2.0 container i am using the following dockerfile to ensure the correct root certificate and the nuget.config:

FROM microsoft/aspnetcore-build:2.0
COPY ./ca.cer /usr/local/share/ca-certificates/ca.crt
COPY ./nuget.config /src/nuget.config
RUN ["update-ca-certificates"]

The nuget.config contains the following:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="NuGet" value="https://api.nuget.org/v3/index.json" /> <add key="myprivateTFS2018" value="https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/FeedName/nuget/v3/index.json" /> </packageSources> <packageSourceCredentials> <myprivateTFS2018> <add key="Username" value="localTFSUser" /> <add key="ClearTextPassword" value="password" /> </myprivateTFS2018> </packageSourceCredentials> </configuration>

Can anyone try to reproduce the issue with this informations?

[jainaashish]

@DarkChaos can you try passing configFile parameter with absolute path to your nuget.config with restore command and see if that works? Also, set verbosity to detailed and share the full logs.

[DarkChaos]

To test the possibility to log in to the Tfs I have tried the following from the build container:

curl --ntlm -u localTFSUser --url https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/FeedName/nuget/v3/index.json

the Result looks good:

{"@context":{"@vocab":"http://schema.nuget.org/services#","comment":"http://www.w3.org/2000/01/rdf-schema#comment","label":"http://www.w3.org/2000/01/rdf-schema#label"},"resources":[{"@id":"https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/bd8f5fc3-9813-4c56-8942-076923467d88/nuget/v2/","@type":"PackagePublish/2.0.0"},{"@id":"https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/bd8f5fc3-9813-4c56-8942-076923467d88/nuget/v2/","@type":"LegacyGallery/2.0.0"},{"@id":"https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/bd8f5fc3-9813-4c56-8942-076923467d88/nuget/v3/registrations2/","@type":"RegistrationsBaseUrl/3.0.0-beta"},{"@id":"https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/bd8f5fc3-9813-4c56-8942-076923467d88/nuget/v3/query2/","@type":"SearchQueryService/3.0.0-beta"},{"@id":"https://myprivateTFS2018.domain.net/DefaultCollection/_packaging/bd8f5fc3-9813-4c56-8942-076923467d88/nuget/v3/flat2/","@type":"PackageBaseAddress/3.0.0"}],"version":"3.0.0-beta"}

@jainaashish I executed the dotnet restore command with your requested options, this is the Result:
dockerdotnetrestore.log

I hope it helps to figure out the problem

[arunjvs]

Folks, using API key as the ClearTextPassword for packageSourceCredentials instead of apikeys worked for me for restore (with VSTS). Set the Username to the user who owns the API key.

[DarkChaos]

I tried @arunjv's recommended way, but this doesn't work for TFS2018.
Tomorrow I'll try it against VSTS.

[arunjvs]

Please note that API keys mean different things based on your server. For VSTS, a Personal Access Token (PAT) with read access to nuget endpoints is what I meant.

[jarrettv]

I'm also having this issue on windows 10 (non container) and in a docker container using a jfrog artifactory.
* Version *
2.1.300-preview1-008174

This is preventing me from moving forward with a bitbucket pipeline. Also, dotnet nuget push and nuget restore works perfectly fine.

[niraj-bpsoftware]

Hi @arunjvs ,
I am still getting same issue after puting API key as ClearTextPassword. dotnet build/restore picks up only private nuget source.
My Nuget.Config:
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="nuget.org" value="https://api.nuget.org/v3/index.json"/> <add key="BPNuget" value="http://myprivatenugetserver/nuget/" /> </packageSources> <packageSourceCredentials> <BPNuget> <add key="Username" value="<<NugetOwner>>" /> <add key="ClearTextPassword" value="<<APIKey>>" /> </BPNuget> </packageSourceCredentials> <packageRestore> <add key="enabled" value="True" /> <add key="automatic" value="True" /> </packageRestore> <bindingRedirects> <add key="skip" value="False" /> </bindingRedirects> <packageManagement> <add key="format" value="1" /> <add key="disabled" value="False" /> </packageManagement> </configuration>

[arunjvs]

@niraj-bpsoftware I'd recommend seeing if the username and password work with the server with basic authentication separately - perhaps using a curl command mentioned above. Also can you be more clear by "picks up only private nuget source". Nuget loads multiple config files in order and this affects from where packages are restored.

[greatkeke]

@DarkChaos I have the same issue with you on MacOS. Did it work now?

[DarkChaos]

Sorry for the late response. Right now I am using a Workaround. First i run a dotnet restore with restore target to a local path. Then I copy the folder into the build container witch I extended with a nuget.config file witch is tageting this container local path as Package source.

In the next days I will upgrade to DevOps Server 2019 witch should solve this issue as mentiont in release notes.

Simplify authentication using the new cross-platform Credential Provider for NuGet
Interacting with authenticated NuGet feeds just got a lot better. The new .NET Core-based Azure Artifacts Credential Provider works with msbuild, dotnet, and nuget(.exe) on Windows, macOS, and Linux. Any time you want to use packages from an Azure Artifacts feed, the Credential Provider will automatically acquire and store a token on behalf of the NuGet client you're using. You no longer need to manually store and manage a token in a configuration file.
To get the new provider, head to GitHub and follow the instructions for your client and platform.