It's also convenient to use SSH protocol.
Enabling 2FA on github affects pushing to/pulling from a repository only if you are using HTTPS as the git protocol. If you're using SSH already it will be unaffected.
For pushing/pulling with HTTPS you will need to generate an HTTPS "token" to use as the password instead of using your web account's password.
when pushing (git push) to Azure DevOps, Bitbucket, or GitHub, a window will automatically open and walk you through the sign-in process. (This process will look slightly different for each Git host, and even in some cases, whether you've connected to an on-premises or cloud-hosted Git host.) Later Git commands in the same repository will re-use existing credentials or tokens that GCM has stored for as long as they're valid
If someone doesn't have a smartphone or other mobile device, and is running Windows on his laptop, is there a way to set up 2FA at Github, or is he just SOL?Many password managers that you might use, like Keepass, or 1Password, can also function as TOTP generator. Of course you should evaluate the security implications of this. It's definitely a step down from having the secret stored on a separate device (mobile phone).
"Classic" github tokens are about 36 random characters long.And SSH private keys are much longer than that. And is an asymmetric system, so the private key is never transmitted. Plus SSH keys have the ability to protect them with a passphrase (two factor) and optionally remembering this passphrase for the duration of the session built in. I don't understand jumping through so many hoops just to be able to use HTTPS, unless you are behind a very restrictive firewall. But Github allows SSH over port 443, so even that's not a very convincing argument. What advantage do you see of using HTTPS instead of SSH for authenticated access?
Newer "fine-grained" tokens are about 80 random characters long.
These are *much* stronger than your typical web account password.
However the "Git Credential Manager" (sometimes referred to as "Git Credential Manager Core") is a separate project that adds credential management using a system's secure storage (ie., the Windows Credential Manager on Windows) as well as supports actual 2FA authentication.Until you run into an URL of more than 256 characters (happens with some automatically-generated URLs), then the Windows Credential Manager is useless and you have to fall back to plain text store. I haven't seen this issue on Linux or Mac, fortunately.
And SSH private keys are much longer than that. And is an asymmetric system, so the private key is never transmitted. Plus SSH keys have the ability to protect them with a passphrase (two factor) and optionally remembering this passphrase for the duration of the session built in.Just to be clear, what are the numbers: typical SSH keys are 240–512 bits, a 80-character token is 376–480 bits. So the entropy is in both cases in a similar range.
I don't understand jumping through so many hoops just to be able to use HTTPS, unless you are behind a very restrictive firewall. But Github allows SSH over port 443, so even that's not a very convincing argument. What advantage do you see of using HTTPS instead of SSH for authenticated access?The primary reason to even use GitHub are features outside of the Git itself. These are available only through their webapp or, at most, HTTPS-only API. SSH is also a solution inaccessible to most of GitHub audience.
"Classic" github tokens are about 36 random characters long.And SSH private keys are much longer than that. And is an asymmetric system, so the private key is never transmitted. Plus SSH keys have the ability to protect them with a passphrase (two factor) and optionally remembering this passphrase for the duration of the session built in. I don't understand jumping through so many hoops just to be able to use HTTPS, unless you are behind a very restrictive firewall. But Github allows SSH over port 443, so even that's not a very convincing argument. What advantage do you see of using HTTPS instead of SSH for authenticated access?
Newer "fine-grained" tokens are about 80 random characters long.
These are *much* stronger than your typical web account password.
However the "Git Credential Manager" (sometimes referred to as "Git Credential Manager Core") is a separate project that adds credential management using a system's secure storage (ie., the Windows Credential Manager on Windows) as well as supports actual 2FA authentication.Until you run into an URL of more than 256 characters (happens with some automatically-generated URLs), then the Windows Credential Manager is useless and you have to fall back to plain text store. I haven't seen this issue on Linux or Mac, fortunately.
# dedicated key for GitHub
Host github.com
User git
IdentityFile ~/.ssh/myGitHubKey
IdentitiesOnly yes
UpdateHostKeys yes
SSH is also a solution inaccessible to most of GitHub audience.This is an interesting statement.
I don't use a mobile device. 2fast was mentioned earlier, but Github's explanation of 2FA says a phone is required.
Maybe it's just shorthand, and not literally true, but they talk only about a "TOTP mobile app".TOTP is just an algorithm. Any computer can be programmed to run it.
GitHub to require 2FA for all contributors starting from March 13: https://techcrunch.com/2023/03/09/github-to-require-2fa-for-all-contributors-starting-from-march-13-to-secure-the-software-supply-chain/
Nice and simple TOTP tool for linux: OTPClient
Maybe it's just shorthand, and not literally true, but they talk only about a "TOTP mobile app".
I have 10 Github repos, but have never installed git or any github web app. I just use my browser in Windows to create and modify the repos on the site.Would it be a problem, if I asked: what is the motivation behind using GitHub in that instance?
Can someone clarify if the 2FA requirement will apply to me, and if so how I can satisfy it.Yes, it will.
I don't use a mobile device. 2fast was mentioned earlier, but Github's explanation of 2FA says a phone is required.Phone will not be required and, while remain an available option, GitHub discourages this option:
We strongly recommend the use of security keys and TOTPs wherever possible. SMS-based 2FA does not provide the same level of protection, and it is no longer recommended under NIST 800-63B.
I thought GitHub was used mostly by programmers. Was I wrong?Yes, it is used mostly by programmers. You are not wrong in that. But you may be wrong in making additional assumptions about what “being programmer” implies.
Thanks but I moved everything from github to Gitlab.Are you sure, you ran away? Or were misled into believing GitLab is some small, nice company? It s an NASDAQ-traded international corporation at the same scale as GitHub.
I stay away from tech giants because they are arrogant and do whatever they like.
The last thing I'll do is giving them my telephone number.You somehow missed, that GitHub explicitly asks to not use mobile phone for that purpose.
I have 10 Github repos, but have never installed git or any github web app. I just use my browser in Windows to create and modify the repos on the site.Would it be a problem, if I asked: what is the motivation behind using GitHub in that instance?
Yes, it is used mostly by programmers. You are not wrong in that. But you may be wrong in making additional assumptions about what “being programmer” implies.Well, may or may not. I guess I won't be very wrong if I say that git (as well as many other protocols) over ssh is the industry-standard approach. SSH is a well-established and very convenient way of tunnelling IP protocols over an encrypted TCP connection.
And even in this case workers rarely set SSH up themselves.I would fire the developer who can't set up an SSH client without any hesitation. This is one of the very basic skills of the profession.
And even in this case workers rarely set SSH up themselves.I would fire the developer who can't set up an SSH client without any hesitation. This is one of the very basic skills of the profession.
(and I haven't ever met any who couldn't.)
I guess I won't be very wrong if I say that git (as well as many other protocols) over ssh is the industry-standard approach. SSH is a well-established and very convenient way of tunnelling IP protocols over an encrypted TCP connection.
SSH is not particularly common on Windowsa software developer who uses windows is, at least, suspicious, because it's the OS which is specifically designed to kill the programmer's productivity.
As for the platforms that developers use, Windows retains its lead, with 62.33 percent of respondents using Windows for personal use and 48.82 percent using it for work. Linux is number two, with 40 and 40 percent, respectively, while the Mac brings up the rear with 31 and 33 percent.
SSH is not particularly common on Windowsa software developer who uses windows is, at least, suspicious, because it's the OS which is specifically designed to kill the programmer's productivity.
I wasn't aware of that limitation. Do you have a pointer to more information about this behavior? I can' t find any issue or discussion topic about it at the https://github.com/git-ecosystem/git-credential-manager site.It's not a limitation in git credential manager, it's a limitation in Windows Credential Store. We had it with another tool that was using the Windows Credential Store. Looking at https://learn.microsoft.com/en-us/windows/win32/api/wincred/ns-wincred-credentiala (https://learn.microsoft.com/en-us/windows/win32/api/wincred/ns-wincred-credentiala), I'm not 100% sure into what limit we ran. Maybe the one for the credentials blob? Either way, the end result was that we had to fall back to plain text files for secret storage on Windows system (a downgrade in security), while things worked smooth on Mac and Linux systems with their native secret stores.
It depends which version of windows. My main dev workstation is Win7 (couple of years ago it was XP 8) ) and Debian is secondary. I find Win7 more convenient.SSH is not particularly common on Windowsa software developer who uses windows is, at least, suspicious, because it's the OS which is specifically designed to kill the programmer's productivity.