Get rid of default login credentials

Right now we have to explain to all people installing GitLab that they have to submit root and password to login initially.

There are three disadvantages:

1. It is a hurdle when installing GitLab
2. We have to unlearn the previous credential root and 5iveL!fe that can be found all over the internet
3. Having a default password looks insecure (it is ascetic since you have to change it on login)

Can we hotwire Devise so the first screen you see after installation is to set a new root password? This screen would have two fields, password and confirmation, there is no field for the old password.

This would:

1. Make installing GitLab easier
2. Prevent the user searching the net and fining old credentials
3. Would not look insecure

---

What needs to happen:

• On new installations drop people in the root password reset screen without needing to login with default credentials
• Preserve the existing option to set a password for the first user through the command line, they than will not have to reset the password on login

if we show the new password screen as the first screen a user sees when opening the fresh install window. Because if we still show a login screen which the user can enter anything at will, they don't get it either.

@jeroenvanbaarsen Indeed we show a password reset screen (without the old password field), not a login windows.

And it would be best to ship this in 7.13 to prevent a lot of confusion about the default password change.

@sytses I like the idea but not sure about 7.13. Maybe just revert password change for 7.13 so we dont need to do it in hurry and break other things?

Or either someone from core team has time to do it

@dzaporozhets I'm OK with reverting or have someone from core team do it. I know that the current release is pretty tight.

Milestone changed to 7.13

We have to ensure that https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/files/gitlab-config-template/gitlab.rb.template#L168 still works.

In any case we'll revert the change of the password, I've push a revert of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/865 to master.

Sorry about that @rspeicher

@vsizov can you merge https://gitlab.com/gitlab-org/gitlab-ce/commit/b3ab0e4efb6c242cf39805fb8c94c3e6023d15ec and https://gitlab.com/gitlab-org/gitlab-ce/commit/997a3b1d872f6b6b198582677acd67595bb15029 into 7.13 stable?

done. Also created merge request CE -> EE (stable) so I can create rc2

Thanks @vsizov

mentioned in merge request gitlab-development-kit!61 (closed)

At the moment it is possible to set the root password during initial setup. If you use that you can prevent people from beating you to a fresh gitlab instance and becoming admin.

Whatever we change the current setup into, I think it would be good to design the new thing so that there is still/again a way to prevent users from becoming admin by reaching the gitlab instance first.

"hotwire Devise so the first screen you see after installation is to set a new root password" is as secure as the current situation (root/5iveL!fe) but at least we now have an option to be safer by overriding the password during initialization. That option should not be lost.

@jacobvosmaer did you see https://gitlab.com/gitlab-org/gitlab-ce/issues/1980#note_1622291 ?

@sytses I did not click the link but I see that it is about the same thing I mentioned above. Now it is written out in this issue. :)

@jacobvosmaer Glad to see we're both on it :)

At the moment it is possible to set the root password during initial setup. If you use that you can prevent people from beating you to a fresh gitlab instance and becoming admin.

Does this solve the issue? Do you think this can be closed @jacobvosmaer?

Status changed to closed

Status changed to reopened

What needs to happen:

• On new installations drop people in the root password reset screen without needing to login with default credentials
• Preserve the existing option to set a password for the first user through the command line, they than will not have to reset the password on login

Milestone changed to 8.1

Milestone changed to 8.4

Milestone changed to 8.6

Added ~122770 label

Here's how Discourse does this.

1. You set an admin e-mail in the yaml file that is used for their docker boostraping
2. When the site is up you register a new account with the e-mail you put in the yaml file
3. A confirmation mail is sent to you and you complete the registration process.
4. If e-mail is not working you create an account using the command line

@axil we already allow people to set a password from the command line if they are worried about a race to login. I care very deeply about the ease of installing GitLab and don't think the method described is convenient enough.

I know and I agree, just wanted to share another option :)

Reassigned to @rspeicher

@DouweM @sytses So in light of https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/1626, what does this feature actually need to be?

@rspeicher I've added @sytses's comment https://gitlab.com/gitlab-org/gitlab-ce/issues/1980#note_1963281 to the description!

mentioned in merge request !3068 (merged)

mentioned in commit 599a6d78

Status changed to closed by commit 599a6d78

@DouweM thanks for updating the description

The default password for development will remain 5iveL!fe, by the way. I still kind of want to change that to password though.

@rspeicher I don't see why we couldn't

mentioned in commit 2f6ded6d

Status changed to reopened

@rspeicher I haven't thought this true all the way. Now we still have a root credential that we need to communicate to the user. How hard would it be to have the user set both their username and their password?

@sytses Hmm, at that point they'd just be following the standard "Sign Up" procedure like any other user -- we'd have to add logic to automatically make the first signed-up (and probably confirmed) user an admin.

@DouweM What do you think?

Milestone changed to 8.7

mentioned in issue #14688 (closed)

Let's do this in https://gitlab.com/gitlab-org/gitlab-ce/issues/14688

Milestone changed to 8.6

Status changed to closed

Hey folks, removing the default password just broke my server installation scripts where I’m setting up specific GitLab configurations automatically using the GitLab API immediately following an installation.

Without a default password, is there any way I can have a non-interactive setup of a specific Gitlab configuration?

Currently, I am using something similar to this and it breaks in 8.6+, with the first call returning a 401 unauthorised error and things cascading from there.

echo -e "\t* Setting the GitLab root password…"
privateToken=$(curl "${curlSecurity}" -X POST https://${domain}/api/v3/session/ --data-urlencode 'login=root' --data-urlencode 'password=5iveL!fe' | jq --raw-output .private_token)

# Create the Generated account and store its ID.
echo -e "\t* Creating the ${gitlabAccountName} account on GitLab…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X PUT https://${domain}/api/v3/users/1 --data-urlencode "password=${gitlabAccountPassword}"

# Add the SSH key to the account.
echo -e "\t* Adding SSH key to the account…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X POST https://${domain}/api/v3/users/${accountID}/keys --data-urlencode "id=${accountID}" --data-urlencode "title=SSH Key" --data-urlencode "key=${publicKey}"

# Create the repository for sites.
echo -e "\t* Creating sites repository…"
curl "${curlSecurity}" --header "PRIVATE-TOKEN: ${privateToken}" -X POST https://${domain}/api/v3/projects/user/${accountID} --data-urlencode "user_id=${accountID}" --data-urlencode "name=sites" --data-urlencode "description=Site drafts generated by Better Inspector." --data-urlencode "public=true"

etc.

(Where curlSecurity is simply '--insecure' if the script is running with Let’s Encrypt’s staging server.)

Has this change broken this use case or is there a different way I can achieve the same thing? If the former, may I please ask that this change be reverted as this is a core use case for us and one that makes GitLab easier to install and use as part of other systems.

Thoughts?

PS. Not sure if notifications are sent for closed issues, so pinging @sytses & @rspeicher :)

mentioned in issue #15589 (closed)

I'd like to second @aral 's issue. I am using GitLab as part of a docker compose for a build box that acts as a starter for our projects. I want to import several projects into GitLab prior to logging in to the UI, but this change has stopped me from being able to do so. Perhaps its possible to add a hook that allows you to activate the root user via CLI?