6 ms·

So ssh key is still fine. Nothing to see here. Move along.

• nine_k 6y ago
  The most interesting bit here for me is that some users are not using SSH keys for git operations. I wonder how many.
  • strogonoff 6y ago
    Which Git implementations, apart from reference CLI, support SSH key authentication? Isomorphic Git (which we use) doesn’t, for example. Not sure I particularly want it to, either—such a feature would probably bring in a host of dependencies but not much to the table compared to a scoped PAT.
    • terinjokes 6y ago
      Most should, or at least have it on the roadmap. There are many Git repositories, off GitHub, that are only accessible with SSH authentication.
      • strogonoff 6y ago
        Really? Why? Seems like it would unnecessarily restrict the range of compatible clients.
    • nine_k 6y ago
      I suppose GIT implementations are mostly transport-agnostic, and specific apps connect them to remote transports. E.g. JGit is widely used and has no notion of SSH keys, but GitBlit can serve a GIT repo over SSH using JGit, and JetBrains IDEs can access GIT repos served over SSH using some kind of pure Java SSH implementation (not sure which); I remember they used to use JGit, too.
    • tialaramex 6y ago
      At least Jgit (the Java implementation) does this correctly. It seems very weird to do SSH at all without using SSH keys. The core SecSH (ie SSH 2) protocol design assumes you have SSH keys, offering password authentication only as an optional extra feature. Now of course the IETF does not have an enforcement arm, and I have seen implementations that don't work like that, but to me this is an obvious red flag, like a stub plugged in to stop the seat belt alarm going off, "I know that what I'm doing is very stupid, so I worked harder to do it anyway". OK then.
      • strogonoff 6y ago
        I don’t mean using SSH without keys (?), I mean why use SSH instead of HTTPS? I see about two possible cases: 1) One uses Git CLI and wants to get rid of incessant password prompts this way. 2) One has a setup in which multiple servers access a private Git repo, and wants each server to use different credentials. This doesn’t seem worth the trouble in simpler scenarios when the user accesses Git from one or two personal machines and is entirely fine just changing their password/revoking PAT if it is compromised.
        • tialaramex 6y ago
          Because SSH actually delivers appropriate user security? In HTTPS the model is, you and the server both know a secret, your "password" and then you... just tell them your secret each time to authenticate. That's a pretty good model if you're a ten year old playing forts out in the woods, but it's far below what we ought to be achieving for a service like this. It's true that this plaintext password authentication is normal for the web, which is basically Tim (Berners-Lee)'s fault but that doesn't magically make it a good idea, and it makes sense that GitHub doesn't want "Yes it's crap but it's no worse than the web" to be all they're delivering.
          • strogonoff 6y ago
            Care to share any specific advantages, aside from the general notion of “appropriate security”?
  • jfarmer 6y ago
    GitHub kinda sorta recommends HTTPS instead of SSH in a few places, e.g., https://docs.github.com/en/free-pro-team@latest/github/getting-started-with-github/set-up-git#next-steps-authenticating-with-github-from-git https://docs.github.com/en/free-pro-team@latest/github/getti...
    • kemayo 6y ago
      HTTPS works more-easily with command line git on Windows, in my experience. I switched a lot of my checkouts on Windows to those URLs.
      • voxic11 6y ago
        I haven't had any issues using the official Windows distribution of OpenSSH. After adding my ssh keys to the ssh-agent it just works. https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse#installing-openssh-with-powershell https://docs.microsoft.com/en-us/windows-server/administrati...
        • kemayo 6y ago
          I'll admit that part of it could just be that I've been using the stuff that comes with the git-scm.com distribution of git for windows.
    • tidepod12 6y ago
      Even in the originally linked article, they recommend HTTPS over SSH: >What you need to do today: For developers, if you are using a password to authenticate Git operations with GitHub.com today, you must begin using a personal access token over HTTPS (recommended) or SSH key by August 13, 2021, to avoid disruption.
  • spondyl 6y ago
    Some enterprises may not be able to, such as those that block SSH ports, including the alternative non-22 port that Github hosts. Yes, that can also include enterprises who contribute to open source on Github yet block port 22 network wide. It's silly.
    • jlgaddis 6y ago
      If you'd like to, you can shoot yourself in the head repeatedly with a nailgun. Don't expect any sympathy from me afterwards, however, when you're whining about how bad your head hurts. What you describe is a problem the organization has created for themselves. If they can't also come up with a solution for themselves, well, that's their problem, I guess. Stupid hurts. As long as they're only shooting themselves with the nailgun and no one else, I'm fine with 'em doing it. Hell, I'd probably show 'em how to load it. -- Pro-tip: $ ssh -T -p 443 git@ssh.github.com
  • japanuspus 6y ago
    One use case: you cannot link the same ssh-key to multiple github accounts. I have my personal and work projects on the same machine, and to get around this issue I use https authentication for one of the accounts.
    • weaksauce 6y ago
      you could make two different keys and have a shell script to ssh-add them to the ssh agent to be used. #! /usr/bin/env sh ssh-add ~/.ssh/id_github ssh-add ~/.ssh/id_github2 or something like that and then just name it sshadd on the path or create an alias in your login script alias sshadd="ssh-add ~/.ssh/id_github && ssh-add ~/.ssh/id_github2"
      • jlgaddis 6y ago
        There's a few ways to try to "workaround" this issue, typically involving multiple "Host" entries in ~/.ssh/config. I haven't actually tried it yet myself, but I think my preference would be to set the "IdentityFile" option to an environment variable (i.e., "${SSH_IDENTITYFILE}") in my ~/.ssh/config file, within an explicit "Host" definition for "github.com"). In my shell initialization files, I'd set $SSH_IDENTITYFILE to either "%d/.ssh/id_ed25519_github_personal" or "%d/.ssh/id_ed25519_github_work" (for example), depending on which I wanted to be the default. When I wanted to use the other account, all I would need to do would be change which of the keys $SSH_IDENTITYFILE pointed to. -- Pro-tip: you'll also want to set "ControlPath none" and "IdentitiesOnly yes" for "Host github.com".
  • 0xbadcafebee 6y ago
    Personal Access Tokens provide both simpler and better security controls than SSH, so you end up using them in enterprises. You can't create an SSH key with select role permissions like you can with a Personal Access Token. But you do need a PAT to use the API. So you can either have one PAT + one SSH key, or just use one PAT and no SSH key. (Or multiple PATs, for fine-grained access control) If you use multiple SSH keys in GitHub (which you should be, to access different things) then you have to manually juggle which SSH key you're passing when you pull each repo, because GitHub will just take the first SSH key you have in your ssh-agent that has an account in GitHub. You won't know from looking at a Git URI ("ssh://git@github.com") which one is needed. OTOH, with PAT, you can either make a URL like ("https://user@github.com https://user@github.com") to pre-specify which user to use, or use "https://github.com https://github.com" and specify user and PAT at auth time. Authentication using SSH requires first accepting the host keys of Github.com, which can rotate, so you have to decide if you're going to bake the host keys into a container, or require a user to accept them (and know when they change if it's a real GitHub key change or a hacker). Or ignore host keys and lose all the security of SSH encryption. The alternative, HTTPS + PAT, requires no such operations, carries less risk, and is less work to implement. And of course some networks block port 22.
    • tialaramex 6y ago
      You can configure SSH and Git to use separate keys if that's what you want (although for many people I'd recommend separating far more e.g. if you have work credentials and personal credentials, don't just segment GitHub, run everything on separate physical hardware, or at least a VM) A mistake lots of people make in this case though is they don't set IdentitiesOnly (in OpenSSH). IdentitiesOnly tells SSH that even if it knows how to authenticate as, say, 'me', if you've told it to authenticate as 'employee' in a particular configuration it should insist on only authenticating as 'employee' never 'me'. If you don't do that you can get confusing behaviour (and of course a privacy hole) on GitHub if your SSH agent knows your 'me' credentials and you try to use an account set to 'employee' credentials, as it uses the wrong ones.
      • Macha 6y ago
        Also if you have a lot of keys set up and don't tell it to use a specific key, you can get login failures as the first 5 it tries aren't correct
  • u801e 6y ago
    You could effectively get 2FA if: 1. your private key requires a passphrase to decrypt or 2. Github could be configured to require both the private ssh key as well as a username and password to authenticate