I need a lesson on gitlab security

[Fred Wright]

On Sun, 15 Mar 2026, Hal Murray via devel wrote:

> Many years ago, I told gitlab my ssk public key and git push just worked.
>
> A while ago, it started asking me for a password.  Annoying, but no big
> deal since I don't push very often.  (There is a bug in the login popup.
> Anybody know how to report things like that?  It wants a user name, but
> the typin box says password.]

If it's actually using SSH, then AFAIK it shouldn't be asking for a 
password, but will need your SSH-key *passphrase* if you're not using 
ssh-agent.

> Now, when I try it, I get this error blurb:
>
> remote: HTTP Basic: Access denied. If a password was provided for Git
> authentication, the password was incorrect or you're required to use a
> token instead of a password. If a token was provided, it was either
> incorrect, expired, or improperly scoped. See https://gitlab.com/help/topic
> s/git/troubleshooting_git.md#error-on-git-fetch-http-basic-access-denied
>
> I don't remember any announcement or discussion of this area.  Did I miss
> something?  Can somebody give me quick lesson?
>
> Is there a flag I can set to go back to useing ssh rather than HTTP?

Assuming you're using the git command-line tool, then whether it uses SSH 
or HTTPS is determined by the way you have the remote configured.  You can 
easily check this with "git remote -v" while in your local repo.  E.g.:

--------------------------------------------------------
MacPro:ntpsec fw$ git remote -v
origin	git at gitlab.com:fhgwright/ntpsec.git (fetch)
origin	git at gitlab.com:fhgwright/ntpsec.git (push)
upstream	git at gitlab.com:NTPsec/ntpsec.git (fetch)
upstream	git at gitlab.com:NTPsec/ntpsec.git (push)
--------------------------------------------------------

The "git" protocol runs over SSH, and is based on SSH authentication.

In the above, "upstream" is the main repo, and "origin" (the default from 
"git clone") is my GitLab fork.  Note that "git" via SSH is being used in 
all cases, regardless of whether I have write access or not, since the 
access is determined on the server side.

Typically, the initial HTTPS vs. SSH setup comes from which option you 
selected when obtaining the clone URL from the website.

If your remote configuration is wrong, you can fix it with "git remote" 
(see the manpage).

BTW, the above setup is desirable even if you have write access to the 
main repo.  Any change that's sufficiently complicated or sufficiently 
controversial to warrant a code review is best accomplished via the MR 
mechanism, even if you could bypass it.  And coming from a fork is the 
native habitat of the MR mechanism.

> I don't know anything about tokens.  Is the token stuff the path of least
> resistance?  Why do I want one and/or why are they better than passwords?

I don't know specifically about tokens, but I do know that logging into 
the GitLab website now requires both passing a captcha test and a 2FA 
authentication.  Perhaps "token" refers to the result of all that, which 
isn't made very clear in a command-line tool.

If you need to use HTTPS for some reason, you might see if logging into 
the website with a browser helps.

Fred Wright