jenkey do you have a backup of that instance, in order to try to reproduce the behavior ?

If it's the case, could you try to restart the instance after the plugin update ?

Could you also give us the version of your credentials plugin ?

In order to reproduce also ourself the problem, did you upgrade the plugin using the update-center ? and then you restarted your instance ?

wfollonier, sorry I don't have a backup for this instance. In the meantime, I simply copied the private key from the file, pasted it into the input box and saved the credentials.

I did install the plugin using the update-center, and I restarted Jenkins using the "Restart Jenkins if installation complete and no jobs are running" checkbox. Is that enough or should I ensure to restart the service next time?

After the upgrade and realizing that all my jobs did not work anymore, I downgraded the ssh-credentials-plugin to version 1.13, restarted and all was working again.

BTW, I am using the jenkins RPM from pkg.jenkins.io/redhat-stable.

The credentials-plugin is at version 2.1.17.

We had exactly the same issue, we are on jenkins 2.107.3, we upgraded the plugin to 1.14 and found the only option we had was 'enter directly'. Downgrading the plugin to 1.13 restored the functionality.

In [SECURITY-440 It is stated that 

SSH Credentials Plugin no longer supports SSH credentials from files on the Jenkins master file system, neither user-specified file paths nor ~/.ssh. Existing SSH credentials of these kinds are migrated to "directly entered" SSH credentials.

Thus you need to enter your ssh-key directly. We fixed this by entering our ssh-key into an Environment Variable and loading that into the credentials at boot time.

BTW: The scope of the Credentials need to be SYSTEM not GLOBAL for this version (1.14) to work in "GitHub Organization" type jobs. Maybe this is required on other types of jobs as well.

wfollonier took a look but was not able to reproduce this issue. As far as we know the migration should work correctly. If anyone can reproduce the migration not working please reopen the ticket and comment with the steps to reproduce the issue.

Looking at JENKINS-54746 I think the exception in this comment (users report seeing this in the old data monitor) is the root cause. The migration is gated by the RunScripts permission being active when that code runs, and that code is expected to run as ACL.System, but for some reason it ran as ACL.anonymous. When the exception is thrown in readResolve, perhaps the effect is that the serialized data is totally lost and it is as if no private keys were ever entered. Perhaps this code should be modified to instead just return if that permission is not found to avoid the conversion exception.