5 ms·

Was the whole password to SSH key switch annoying at all for anyone else? Like procedurally its simple but I have a bunch of accounts, a bunch of different repo

Was the whole password to SSH key switch annoying at all for anyone else? Like procedurally its simple but I have a bunch of accounts, a bunch of different repos. It just felt annoying even if the end-result desire for the system operator (GitHub) is maybe desirable... ("our users are better off according to our definitions of security") Let me use a password if I want, these security requirements are becoming increasing absurd - I could realistically see people just checking out of services if these invasive procedures continue. Just kidding, a lad can dream. Yeah it's not rocket surgery to add the ssh key and then clone it to your different machines but if you have strict sprint deadline or something and you haven't pulled from your repo in a day and suddenly you can't run your workflow, then that's really pretty annoying to have to run the context switch and do some random bullshit to appease your vendor's obnoxious requirements. If Millenials ever learn software engineering en-masse maybe they would decry this lack of consent in daily software engineering operations. (Haha jk... not really, but I'm a Millenial so it's ok for me to say this) Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense. EDIT: WOW speak of the devil, I literally just received an email saying on of my earlier keys is about to expire (personal account vs my employer GitHub account). Seriously shoot me in the face, why do I have to constantly update stuff to comply with requirements without getting paid? Just kidding, but almost not. :rage_face:

generationP 5y ago
I have still not figured out how to use the new system from the command line. And I am generally rather familiar with git, just not with ssh. Ended up switching a repo to public just in order to be able to use it. Maybe I should try again and hope there are better tutorials around now than a month ago. The Anubis school of infosec https://external-preview.redd.it/-zmkMWw8GlL5REUZmtcKIPj9PtYLETyr_egrg-LuSfU.jpg?auto=webp&s=b9c78f2d5e2d5554305c78c26e9bb60f43b7e878 https://external-preview.redd.it/-zmkMWw8GlL5REUZmtcKIPj9PtY... is strong on this one.
- arthurcolle 5y ago
  Sorry I'd tell you how I do it but for OPSEC reasons I cannot... Haha just kidding, here what's up - this is what a friend of mine does that has nothing to do with my own operations of course. Probably violating many contractual arrangements bigly but honestly the whole security side of this stuff is so anal retentive that I will, for the greater good of my boy generationP. You just go into your dev settings on GitHub. (Top right when youre on GitHub.com, dev profile pic, click on Settings then on Developer Settings, then you'll be confused because it asks you to register a dumbass GitHub app - ignore this) Then click on "Personal access tokens" on the lower left of the left most menu. Then generate with the desired permissions (wow, guess what most people will select in a rush...? shocking, unimaginable...) Anyways once you have the token, which will only be generated once, so save it down - I just make a environment variable and export it because I have a finite amount of time in my life and this stuff beyond annoys me. The just repoint your local repo clones to an instance with the following convention: git://<username>:<personal_access_token>@github.com/<username OR orgname>/<repo name> Good luck, old sport. Post on here if you have any problems. You can also modify all the crap in your .git subdirectory within a repo but that's deep in the danger zone.
  - generationP 5y ago
    Thanks, but... something's off, and the error message makes no sense: $ git remote set-url origin git://<my userid>:<my token>@github.com/<repository owner's userid>/<repository name> $ git pull fatal: unable to look up <my userid>:<my token>@github.com (port 9418) (Non-recoverable failure in name resolution) In other news, did I mention that the scopes are a bit confusing? I've checked "repo" and nothing else, based on the empirical assumption that the stuff near the top is the most important, but why don't I need, say, "read:public_key", if I am to use ssh? (The set-url worked fine -- the new URL is indeed in the .git/config.)
    - vtbassmatt 5y ago
      Using username/PAT works with https:// https://, not git://. An easier route might be GCM Core (https://github.com/microsoft/Git-Credential-Manager-Core https://github.com/microsoft/Git-Credential-Manager-Core). And of course, disclosure, I'm the product manager for GCM Core and author of this blog post.
madeofpalk 5y ago
invasive?
- arthurcolle 5y ago
  They are inadvertently altering my timeline to accommodate their own security policy so yes, clearly invasive. EDIT: this is kind of a joke, but the spirit is still in play.
scrollaway 5y ago
> Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense. Github is not in a position to "rethink passwords from the ground up". They are however in a position where it's their responsibility to ensure the security of what they host. These changes are good. That you're calling them "absurd" and "security nonsense" speaks volumes, to be honest. And if one of your keys is about to expire (I'm guessing a GPG key since SSH keys traditionally have no expiration), that'd be because you put an expiration date on it. One you chose…
- arthurcolle 5y ago
  You're probably right, I was speaking about authentication on the whole from an industry perspective. I'm allowed to be annoyed with something that disrupts me from Innovating™ so I used my post as an outlet to do just that. P.S. no the email that came is was related to a personal access token for my own special projects account. Maybe they defaulted to some expiration period, don't care enough to go out of my way to find out right now.
- jimmaswell 5y ago
  Password in your head: boo, evil, bad security, speaks volumes if you like them. SSH key stored on multiple devices which amounts to a saved password: wow, so secure, much better. I still don't get it.
iotku 5y ago
>Was the whole password to SSH key switch annoying at all for anyone else? Never was an issue for me because I'd always been using keys in the first place. I imagine it's less common for folks who don't manage servers, but all of my prior ssh usage had switched to keys over a decade ago. >Like procedurally its simple but I have a bunch of accounts, a bunch of different repos. Definitely recommend looking into creating a ssh config if you're using different keys per account. (Notably you can set your IdentityFile (key to use) per host (which can also be set as something arbitrary like "gh-username") There's a pretty friendly post here: https://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/ https://nerderati.com/2011/03/17/simplify-your-life-with-an-... >Let me use a password if I want, these security requirements are becoming increasing absurd I don't want my software dependencies to be compromised just because someone reused a password. >Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense. Keys are rethinking it from the ground up (which seems to be the complaint), though there certainly are challenges in managing keys as well.
- arthurcolle 5y ago
  Yeah you are basically right. I hate passwords with a passion so I guess it is foolish to even complain about passwords in the aggregate but I mean mentally it just adds a layer where I have to vaguely remember if I used passwords or another alternative form of authentication with a specific service. I do a lot of data ingestion work, I run my own servers within a ZeroTier setup that links a bunch of machines together. I can only access it from my machines that have a set SSH key setup, so I agree, that's a great system. I ingest data from a bunch of data providers as well as some exchanges/brokers. But for example, look at the disparity for some of these web operators - Gemini only uses Authy for 2FA management iirc + password, Coinbase is Authenticator (or whatever you want) + password, Interactive Brokers has some weird bespoke setup that requires an initial mobile login and then another layer of auth that I can't fully describe. DigitalOcean is authenticator + password, GitHub is authenticator or SMS + password [I'm referring to actually accessing the website from a client device for all of these] Then they all have API key generation which has variable definitions. AWS is nice for its consistency with its AWS access key + private key combo that you can generate whenever you need with IAM profiles. It's just... this is a lot to even need to know. I wish I didn't have to know the intricacies of all these crazy systems. I want to get some stuff done. I'd be down to have it be biometric or something. I'm tired of having to think about how I log into stuff and managing keys for all this shit. Literally - that's my complaint. It's all too much to keep in my head and I'm frequently frustrated by needing to recall this stuff. Sure, lastpass is fine for what it is and I also do try to keep my SSH keys safely stored for re-use where desired or generate machine specific configurations when that is reasonable for the project specification, but it's really just a headache for me. I'd love a ssh key management solution that doesn't drive me bonkers - if you have any suggestions I'll owe you a coffee next time youre in town lol.
singingboyo 5y ago
I... what? I've never had my ssh key expire, because that's just not a thing. If you don't use it, then I think Github drops it after a year and requires you to add it again, but it's really not hard to put it back in in that case. Also why on earth would I want to type a password every time I do something, even when it was an option I usually cancelled my push and set up an ssh key.
- jfrunyon 5y ago
  > [SSH key expiry is] just not a thing It is, actually. https://manpages.ubuntu.com/manpages/xenial/man1/ssh-keygen.1.html https://manpages.ubuntu.com/manpages/xenial/man1/ssh-keygen.... look for "-V validity_interval". Admittedly that's on the certificate rather than the key itself (yes, SSH keys can have proper CA infrastructure!) and not something most people have to worry about. > Github drops it after a year and requires you to add it again That's pretty clearly what GP was referring to. And I completely understand how annoying it would be, too. Consider this, you might not even use it again before it expires again, but if you don't re-add it promptly you probably won't be able to figure out why stuff isn't working the next time you do use it...
Macha 5y ago
I have never used a password for git. It's always been ssh keys, across github, gitlab, bitbucket, github enterprise, stash, a folder on a server I have, etc. It wasn't something I was familiar with before the first time I used github in 2009 as a teenager, and it did not take too long to figure out. Nowadays if copy/pasting the CLI commands github gives you and putting that in your profile settings is offputting, a lot of GUIs exist that will automate the setup process. It's not something where you're going to lose lots of time adjusting your settings, and it's not like github did not give a lot of warning on this change. There's plenty of security behaviours I find overbearing, but I have to say I'm pretty ok with how github has been handling their transitions.
raxxorrax 5y ago
It is extremely annoying to me. Microsoft goes a similar way for authentication against a lot of their APIs. I dropped some of them because the maintenance isn't worth the benefit anymore. I also don't want to register apps at them and don't want to wait until they acknowledge access. The market is too competitive for that. An overall it doesn't really add security to my threat model. A complicated authentication isn't necessarily a secure authentication. Given, passwords have to be handled with care, but any ssh key could just as well be scraped by the OS vendor as any password or by someone that compromised your system.
lmm 5y ago
> Let me use a password if I want, these security requirements are becoming increasing absurd - I could realistically see people just checking out of services if these invasive procedures continue. Just kidding, a lad can dream. Yeah it's not rocket surgery to add the ssh key and then clone it to your different machines but if you have strict sprint deadline or something and you haven't pulled from your repo in a day and suddenly you can't run your workflow, then that's really pretty annoying to have to run the context switch and do some random bullshit to appease your vendor's obnoxious requirements. If Millenials ever learn software engineering en-masse maybe they would decry this lack of consent in daily software engineering operations. (Haha jk... not really, but I'm a Millenial so it's ok for me to say this) Passwords are just not viable for public-facing services any more. If they let people use passwords, those people would keep getting hacked, and the support burden (or the reputation burden if they just shrugged their shoulders) would be too high. Frankly, between using passwords that you're forced to rotate / expire / use x special characters and y numbers, using some opaque ML system that blocks your login whenever you're travelling, and just actually using ssh keys, I know which option I prefer.

generationP 5y ago

I have still not figured out how to use the new system from the command line. And I am generally rather familiar with git, just not with ssh. Ended up switching a repo to public just in order to be able to use it. Maybe I should try again and hope there are better tutorials around now than a month ago. The Anubis school of infosec https://external-preview.redd.it/-zmkMWw8GlL5REUZmtcKIPj9PtYLETyr_egrg-LuSfU.jpg?auto=webp&s=b9c78f2d5e2d5554305c78c26e9bb60f43b7e878 https://external-preview.redd.it/-zmkMWw8GlL5REUZmtcKIPj9PtY... is strong on this one.

arthurcolle 5y ago
Sorry I'd tell you how I do it but for OPSEC reasons I cannot... Haha just kidding, here what's up - this is what a friend of mine does that has nothing to do with my own operations of course. Probably violating many contractual arrangements bigly but honestly the whole security side of this stuff is so anal retentive that I will, for the greater good of my boy generationP. You just go into your dev settings on GitHub. (Top right when youre on GitHub.com, dev profile pic, click on Settings then on Developer Settings, then you'll be confused because it asks you to register a dumbass GitHub app - ignore this) Then click on "Personal access tokens" on the lower left of the left most menu. Then generate with the desired permissions (wow, guess what most people will select in a rush...? shocking, unimaginable...) Anyways once you have the token, which will only be generated once, so save it down - I just make a environment variable and export it because I have a finite amount of time in my life and this stuff beyond annoys me. The just repoint your local repo clones to an instance with the following convention: git://<username>:<personal_access_token>@github.com/<username OR orgname>/<repo name> Good luck, old sport. Post on here if you have any problems. You can also modify all the crap in your .git subdirectory within a repo but that's deep in the danger zone.
- generationP 5y ago
  Thanks, but... something's off, and the error message makes no sense: $ git remote set-url origin git://<my userid>:<my token>@github.com/<repository owner's userid>/<repository name> $ git pull fatal: unable to look up <my userid>:<my token>@github.com (port 9418) (Non-recoverable failure in name resolution) In other news, did I mention that the scopes are a bit confusing? I've checked "repo" and nothing else, based on the empirical assumption that the stuff near the top is the most important, but why don't I need, say, "read:public_key", if I am to use ssh? (The set-url worked fine -- the new URL is indeed in the .git/config.)
  - vtbassmatt 5y ago
    Using username/PAT works with https:// https://, not git://. An easier route might be GCM Core (https://github.com/microsoft/Git-Credential-Manager-Core https://github.com/microsoft/Git-Credential-Manager-Core). And of course, disclosure, I'm the product manager for GCM Core and author of this blog post.

madeofpalk 5y ago

invasive?

arthurcolle 5y ago
They are inadvertently altering my timeline to accommodate their own security policy so yes, clearly invasive. EDIT: this is kind of a joke, but the spirit is still in play.

scrollaway 5y ago

> Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense. Github is not in a position to "rethink passwords from the ground up". They are however in a position where it's their responsibility to ensure the security of what they host. These changes are good. That you're calling them "absurd" and "security nonsense" speaks volumes, to be honest. And if one of your keys is about to expire (I'm guessing a GPG key since SSH keys traditionally have no expiration), that'd be because you put an expiration date on it. One you chose…

arthurcolle 5y ago
You're probably right, I was speaking about authentication on the whole from an industry perspective. I'm allowed to be annoyed with something that disrupts me from Innovating™ so I used my post as an outlet to do just that. P.S. no the email that came is was related to a personal access token for my own special projects account. Maybe they defaulted to some expiration period, don't care enough to go out of my way to find out right now.
jimmaswell 5y ago
Password in your head: boo, evil, bad security, speaks volumes if you like them. SSH key stored on multiple devices which amounts to a saved password: wow, so secure, much better. I still don't get it.

iotku 5y ago

>Was the whole password to SSH key switch annoying at all for anyone else? Never was an issue for me because I'd always been using keys in the first place. I imagine it's less common for folks who don't manage servers, but all of my prior ssh usage had switched to keys over a decade ago. >Like procedurally its simple but I have a bunch of accounts, a bunch of different repos. Definitely recommend looking into creating a ssh config if you're using different keys per account. (Notably you can set your IdentityFile (key to use) per host (which can also be set as something arbitrary like "gh-username") There's a pretty friendly post here: https://nerderati.com/2011/03/17/simplify-your-life-with-an-ssh-config-file/ https://nerderati.com/2011/03/17/simplify-your-life-with-an-... >Let me use a password if I want, these security requirements are becoming increasing absurd I don't want my software dependencies to be compromised just because someone reused a password. >Passwords are 100% the weakest link in our beep boop chain of trust, of course - we know this. But maybe they should just be rethought from the ground up instead of randomly affecting your users all the time with security nonsense. Keys are rethinking it from the ground up (which seems to be the complaint), though there certainly are challenges in managing keys as well.

arthurcolle 5y ago
Yeah you are basically right. I hate passwords with a passion so I guess it is foolish to even complain about passwords in the aggregate but I mean mentally it just adds a layer where I have to vaguely remember if I used passwords or another alternative form of authentication with a specific service. I do a lot of data ingestion work, I run my own servers within a ZeroTier setup that links a bunch of machines together. I can only access it from my machines that have a set SSH key setup, so I agree, that's a great system. I ingest data from a bunch of data providers as well as some exchanges/brokers. But for example, look at the disparity for some of these web operators - Gemini only uses Authy for 2FA management iirc + password, Coinbase is Authenticator (or whatever you want) + password, Interactive Brokers has some weird bespoke setup that requires an initial mobile login and then another layer of auth that I can't fully describe. DigitalOcean is authenticator + password, GitHub is authenticator or SMS + password [I'm referring to actually accessing the website from a client device for all of these] Then they all have API key generation which has variable definitions. AWS is nice for its consistency with its AWS access key + private key combo that you can generate whenever you need with IAM profiles. It's just... this is a lot to even need to know. I wish I didn't have to know the intricacies of all these crazy systems. I want to get some stuff done. I'd be down to have it be biometric or something. I'm tired of having to think about how I log into stuff and managing keys for all this shit. Literally - that's my complaint. It's all too much to keep in my head and I'm frequently frustrated by needing to recall this stuff. Sure, lastpass is fine for what it is and I also do try to keep my SSH keys safely stored for re-use where desired or generate machine specific configurations when that is reasonable for the project specification, but it's really just a headache for me. I'd love a ssh key management solution that doesn't drive me bonkers - if you have any suggestions I'll owe you a coffee next time youre in town lol.

singingboyo 5y ago

I... what? I've never had my ssh key expire, because that's just not a thing. If you don't use it, then I think Github drops it after a year and requires you to add it again, but it's really not hard to put it back in in that case. Also why on earth would I want to type a password every time I do something, even when it was an option I usually cancelled my push and set up an ssh key.

jfrunyon 5y ago
> [SSH key expiry is] just not a thing It is, actually. https://manpages.ubuntu.com/manpages/xenial/man1/ssh-keygen.1.html https://manpages.ubuntu.com/manpages/xenial/man1/ssh-keygen.... look for "-V validity_interval". Admittedly that's on the certificate rather than the key itself (yes, SSH keys can have proper CA infrastructure!) and not something most people have to worry about. > Github drops it after a year and requires you to add it again That's pretty clearly what GP was referring to. And I completely understand how annoying it would be, too. Consider this, you might not even use it again before it expires again, but if you don't re-add it promptly you probably won't be able to figure out why stuff isn't working the next time you do use it...

Macha 5y ago

I have never used a password for git. It's always been ssh keys, across github, gitlab, bitbucket, github enterprise, stash, a folder on a server I have, etc. It wasn't something I was familiar with before the first time I used github in 2009 as a teenager, and it did not take too long to figure out. Nowadays if copy/pasting the CLI commands github gives you and putting that in your profile settings is offputting, a lot of GUIs exist that will automate the setup process. It's not something where you're going to lose lots of time adjusting your settings, and it's not like github did not give a lot of warning on this change. There's plenty of security behaviours I find overbearing, but I have to say I'm pretty ok with how github has been handling their transitions.

raxxorrax 5y ago

It is extremely annoying to me. Microsoft goes a similar way for authentication against a lot of their APIs. I dropped some of them because the maintenance isn't worth the benefit anymore. I also don't want to register apps at them and don't want to wait until they acknowledge access. The market is too competitive for that. An overall it doesn't really add security to my threat model. A complicated authentication isn't necessarily a secure authentication. Given, passwords have to be handled with care, but any ssh key could just as well be scraped by the OS vendor as any password or by someone that compromised your system.

lmm 5y ago

> Let me use a password if I want, these security requirements are becoming increasing absurd - I could realistically see people just checking out of services if these invasive procedures continue. Just kidding, a lad can dream. Yeah it's not rocket surgery to add the ssh key and then clone it to your different machines but if you have strict sprint deadline or something and you haven't pulled from your repo in a day and suddenly you can't run your workflow, then that's really pretty annoying to have to run the context switch and do some random bullshit to appease your vendor's obnoxious requirements. If Millenials ever learn software engineering en-masse maybe they would decry this lack of consent in daily software engineering operations. (Haha jk... not really, but I'm a Millenial so it's ok for me to say this) Passwords are just not viable for public-facing services any more. If they let people use passwords, those people would keep getting hacked, and the support burden (or the reputation burden if they just shrugged their shoulders) would be too high. Frankly, between using passwords that you're forced to rotate / expire / use x special characters and y numbers, using some opaque ML system that blocks your login whenever you're travelling, and just actually using ssh keys, I know which option I prefer.