Windows Build Agent - unable to connect to nuget api - (dotnet restore)

Using Jenkins
1

Hello.
I’am using Jenkins v2.346.1 with a (Windows Server Build Agent on VM / AWS ES2 Windows Server 2019).
In a simple C# project I want to “dotnet restore” my packages. First stage!: clean

powershell "dotnet restore"
powershell "dotnet clean"

The issue:
ONLY with using my Jenkins pipeline I cannot restore the nuget packages because the connection to api.nuget.org is not established.
(Unable to load the service index for source https://api.nuget.org/v3/index.json)

The facts:
Yes, It already worked. Since a few weeks it doesn’t anymore.
Yes, I can manually dotnet restore logged into the Build Agent VM via normal windows user
Yes, I can manually dotnet restore logged into the Build Agent VM via NT/Authority System user (whoami user is displayed when using Jenkins file for output)
Yes, the nuget.config is setup correctly (Proxy) => as it works also manually (the user nuget.config AND the System32 nuget.config, also tested without)

For whatever reason the connection only within the Jenkins build pipeline seems to be broken because of old cipher suites used. Where do they come from?
What is the difference between using NT/Authority System user and let Jenkis do exactly the same stuff?

What kind of connection is used by Jenkins when using a Windows Build Agent to restore nuget packages?

Maybe someone got this issue before… (Google is not the solution… you will find this problem, but the answeres are only: nuget.config/proxy/typos… I done with this…

2

Are you in a corporate environment? Did someone add or remove a proxy? That feels like what is going on.

Otherwise it’s not really a Jenkins issue. Jenkins is just running that command, so the cipher suite would be something that dotnet command is doing.

I know for windows installs, lots of people don’t realize that the default setup for agents runs the agent as a seperate local service account. So maybe something is not configured for that user.

3

Yes its a Corporate env. The user that is running it is a NT Authority System User.
You are right. We figgered out that running the Slave with another User fixed the issue. Thank you!

4

Hi there,

As a reminder, the term “slave” to refer to an agent has been deprecated since 2016. Please refer to On Jenkins Terminology Updates for more details. We request you update your post.

Thanks,
Gavin Mogan