I can't duplicate the problem that you've described. Maybe there are details missing from your description?

Steps I used while failing to duplicate the problem:

1. Download Jenkins 2.105 (from 2012)
   $ wget https://fallback.get.jenkins.io/war/2.105/jenkins.war
2. Run Jenkins 2.105
   $ mv jenkins.war jenkins-2.105.war && JENKINS_HOME=$(pwd) java -jar jenkins-2.105.war
3. Answer the password prompt with the random password written to the Jenkins startup log
4. Choose to install no plugins (since update center does not support that old a version)
5. Add myself as a user with the same random password as generated by Jenkins (also tried a more common password with same results)
6. Stop Jenkins 2.105
7. Download Jenkins 2.277.1
   $ wget https://get.jenkins.io/war-stable/2.277.1/jenkins.war
8. Start Jenkins 2.277.1
   $ mv jenkins.war jenkins-2.277.1.war && JENKINS_HOME=$(pwd) java -jar jenkins-2.277.1.war
9. Login with the username and password created by Jenkins 2.105

The passwordHash written by Jenkins 2.105 looks like this:

<passwordHash>#jbcrypt:$2a$10$oaFBLELplTbFIOw7khYbjusCMnXOnaP7vhNpEpBxW7PVeQRwbQvKW</passwordHash>

The passwordHash written by Jenkins 2.277.1 looks like this (in a file with a version 10 XML tag inside):

<passwordHash>#jbcrypt:$2a$10$oaFBLELplTbFIOw7khYbjusCMnXOnaP7vhNpEpBxW7PVeQRwbQvKW</passwordHash>

Maybe the password hash from much earlier than 2.105?

Did you follow the instructions in the Jenkins 2.277.1 upgrade guide by updating your authentication plugins before the upgrade to 2.277.1?

Hi Mark, thank you for a throughout and quick followup.

I can confirm that the passwordHash did not contain a hash starting with #jbcrypt, something that suggests that the install was even older than I stated. I think it might be as old as from 2010.

Another issue that I had was that there were two admin entries in the users directory, but only one in the users.xml file. I do not know if the other entry was seen by jenkins at all or if if just existed in the directory without affecting any code at all.

> Did you follow the instructions in the Jenkins 2.277.1 upgrade guide by updating your authentication plugins before the upgrade to 2.277.1?

I have made sure that all plugins have been up to date at all times. It was my understanding reading the guide that that was what was needed.

Thanks tarjei_asku. I'm not sure which change would cause very old password hashes to not be interpreted correctly in 2.277.1 when they were correctly interpreted in 2.268, but that is a relatively narrow range of changes that I can search to find what I missed in the changelog and upgrade guide. Thanks again for doing the research to identify the issue. Once I can duplicate the problem I'll include the item in the changelog and in the upgrade guide.

I upgraded from 2.268.

To clarify, you used the 2.268 weekly release from November, and updated to the LTS release 2.277.1, switching release lines in the process?

I couldn't find a change in the specified version range that looks related. My first guess was my recent(ish) work on removing DES from Protector (/me sighs), but that was back in 2.236.

https://groups.google.com/g/jenkinsci-users/c/zwm_iGQLf-I/m/d6xl5bszCQAJ indicates a regression in 2.266, but this report states it still worked in 2.268.

Hi Guys!
I've tried to update to latest LTS (v2.277.2) yesterday and ran into the same issue as described by the reporter. Our Jenkins instance runs since 2012 and was continuously updated.

However, all existing users still use SHA password hashes (there wasn't any migration to jbcrypt) and since commit https://github.com/jenkinsci/jenkins/commit/a9ca5ef3d4c97937636bf3c585f4232514279b14 the CLASSIC password encoder has gone from hudson.security.HudsonPrivateSecurityRealm.
As a consequence, no user could log in anymore and I had to rollback to v2.263.4 where login still works.