We have a private repository on GitHub for our company's project. Initially i started off the repository, therefore current owner is me. But as the team grew we started to feel an urge to create a organization on GitHub which enables roles etc.
Current situation:
several distinct development machines are connected to the repository
by 'personal access tokens'. So their authentication is cached globally.
Live (production) server that is connected to the repository, with an 'SSH key' .
Test (development) server also connected to the repository. But it asks for authentication each time (username and password/PAT)
In this case, if a transfer the ownership of the repository from my account to company's organization: what I'll possibly break ? I've read that GitHub will redirect old URL to the repository will point to the new URL. But still, i think SSH key on the live server is likely to fail.
Can you please inform me about possible outcomes ? Thank you.
Edit 1: Results
Here is the results if anyone stumbles upon this post.
Old remote URL worked just fine, as stated in GitHub docs on transferring ownership. But we decided it's for the best to change the remote URL to new one, just in case.
Development machines with PAT worked just fine. No issue has been encountered.
We updated Live (production) server's origin remote URL right away so there won't be any funny business. SSH key had to be updated to comfort the new URL.
Test is still using old URL without any issue.
Generally, personal access tokens work based on the owner's access permissions, so if you continue to retain access to the repository, then those will continue to work. The same is true of SSH keys associated with the account. Similarly, other users who have their own PATs or SSH keys and continue to retain access will have those PATs or keys continue to work.
Ideally for most automated system purposes, you'll want to use SSH with deploy keys, because those are associated with the repository, so if someone leaves the company, things won't break. If you need to have individual users log into a server and pull, just have them forward their SSH agent.
If you need PATs for automated processes, such as for making API calls, you'll want to make a bot account and grant it access to the repository. That's much easier than trying to use individual people's PATs and again, it prevents employees who leave the company from breaking things when they lose access.
Related
I'm trying to push some files to my new(second) Github account through terminal. I've tried so many times with similar questions, but it keeps saying this below
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
To be more specific, at first, I had a Github account(First) and I was able to do 'push' or 'pull' function using SSH URL, but this problem happens when I try to push some files to a new repository of the new account(Second). I've also tried removing the URL, but still it didn't work, and now I'm at a loss about what to do.
Someone said I can use Https URL instead of SSH URL, but I want to resolve this problem not avoiding things that happened.
Thanks!:D
SSH authentication keys are only valid for an Account.
If you made a new Github account and create the repository with this account, you will need to grant read permission at least for your first Github account to be able to access it.
today I've moved my private github repository to newly created organization (of which I'm an owner). I've changed my remote origin to git#github.com:organization/repo.git. I'm not able to push to remote because I've got an error saying
Error: Permission to organization/repo.git denied to MyGithubUsername.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
I've checked that my account is owner of organization and repository exists.
Disable third-party application access restrictions as suggested in atom/github #1010.422882361.
I ran into this problem today and indeed as Ephellon Dantzler suggests, disabling 3rd-party access restrictions fixed it.
However, I did not really like that solution so I started reading the documentation. On the About OAuth App access reistrictions page, Github mentions that enabling 3rd party restrictions will block:
SSH keys created before February 2014 immediately lose access to the organization's resources (this includes user and deploy keys).
I created my key well before that so I just created a new SSH key and added to Github following their instructions.
After that, I was able to interface with my organization's private repository even when 3rd-party access restrictions was enabled.
I managed to find an answer. Maybe I did something wrong, or maybe it was because of github issues, but even if I was stated as an owner of Organization I had only rights to read repository. I couldn't change permission for myself because "you can't change permission for owner". I changed permissions for all members to admin, and because for now I'm the only one member of organization it's not a big deal.
The solution I found to this problem was creating a P.A.T (Personal Access Token) and using it in the spot of my password when pushing to the repo.
The way you can create a P.A.T is by going to:
Github.com >Login> Settings> Developer Settings> Personal Access Tokens > Generate New Token. I selected all the options for my token and then copied the token that was generated and used it as my password when I was asked to enter my credentials.
This took me a few hours to figure out and was very frustrating. I hope this info can help someone else!
Using GitHub Desktop..I was having a weird bug where I was owner of the organization, and admin of the repo(I had full rights) on my organization's repo. I decided to go into the command line, and push from there (Type "git push") and that fixed it!
It pushed, and I could now push from GitHub Desktop again.
Weird, but hope it helps someone!
For me, everything was ok in the Settings and with my key. Yet Github Desktop could not push (or even fetch) to/from the remote because it didn't trust the IP address. To find and fix I switched to the CLI and ran:
git fetch
which replied with
The authenticity of host 'github.com (140.82.114.4)' can't be established.
RSA key fingerprint is SHA256:<long string>.
Are you sure you want to continue connecting (yes/no)?
therefore revealing the issue. Either Github has changed their IP or I hadn't connected to this repo on my new machine (with the old key). Replying yes added the IP to my .ssh/known_hosts and then Github Desktop worked just fine again.
Warning: Permanently added 'github.com,140.82.114.4' (RSA) to the list of known hosts.
So I ran into this issue recently with an SSH key generated in 2018 and Ephellon Grey's answer pointed me in the right direction. My personal SSH key was added to GitHub by SourceTree and SourceTree was not an authorized third-party app on my organization page. Hence pushes authorized with that SSH key were being rejected. I just had to grant third-party access to SourceTree on the organization and now I can push to repos contained within.
I have followed the process described in Multiple GitHub Accounts & SSH Config (stefano's answer) and have set up SSH access to multiple repositories using deploy keys. I've tried that on repositories of a specific GitHub organization and it works fine - I can pull and push changes. I've also tried this on my user area and it still works great.
However, when trying this on repositories in another GitHub organization (e.g. when doing a git push) it fails with the following error
ERROR: Permission to XXXX/YYYY.git denied to deploy key
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
When checking SSH access through ssh -T I get
"Hi XXX/YYYY! You've successfully authenticated, but GitHub does not provide shell access."
which suggests that SSH should be working.
I have gone through the organization settings (main page for GitHub organization > Settings) and they have pretty much identical settings, except from what you would expect to be different e.g. contact email etc.
I was wondering if anyone has any ideas about what could be causing this. Are there any more organization settings somewhere by any chance?
ERROR: Permission to XXXX/YYYY.git denied to deploy key
This looks like you are trying to push using a deploy key. This key is used for deployment and therefore only to read-only access of your repository. Make sure you have the key which is enrolled in your github account, make sure it is used (IdentityFile in ~/.ssh/config) and get rid of the deploy key from the standard location which is picked by default (~/.ssh/id_{rsa,dsa,ecdsa,ed25519}). Note, that if there are more "valid" keys, only the firs succeeds.
Everyday I must launch new EC2 instances (or any other server with public IP). I'm provisioning it with Chef, creating vhosts, uploading databases etc.
I need to clone there a couple of private repos from GitHub. What would be the best way to do this?
I could manually generate an ssh key, and add it for each GitHub repo I need, then run the script - but it's a lot of work.
I could go for git clone git://user:password#github.com/*****/*****.git, but obviously I don't want to store my password this way
What else?
Is there any way to:
store a private key (or password?) in a recipe/cookbook or
generate new key, and synchronize it via API with GitHub (but this would lead to hundreds of keys in my GitHub account)
Store your key in an S3 bucket and use IAM roles/policies to control access. Citadel makes this easy to integrate with Chef. See my post about secrets management with Chef for a summary of other options.
Shameless plug: the deploy_key cookbook.
I created this cookbook with this precise use case in mind. It manages the entire lifecycle of deploy keys in GitHub, BitBucket and GitLab. It creates a key locally (so that it never has to be sent over the network), adds it to the repo as a deploy_key (read-only, so that these keys don't ever push changes to the repo), and can be used to delete the key files and remove the keys from the repo.
All actions are idempotent so if you're afraid your repos will be flooded with too many deploy_keys you can either remove the key from the repo after use (via Chef, :remove action), or have a periodic clean up task to delete all deploy_keys. Next time Chef runs, it will notice that the key is absent and re-add it.
The only secret you need to protect are the credentials to the repo, which can be protected in the same way you do other secrets.
I've set up a GitHub repository on my laptop today. I can submit code and all ... but now I want to have the same access with my PC. Do I need to configure the SSH keys etc all over again, with every box I want to work with?
You need SSH access on all computers that will commit code or sync with a private GitHub repository. You have two choices:
Use the same SSH key on all your client computers.
Use a different SSH key on each client computer.
Either way, your authorized SSH keys must be configured on GitHub to allow proper access. Obviously, option #1 is easier to manage, unless your Windows or Mac SSH client doesn't handle OpenSSH keys properly.
Git with apache (http or https), Nice and easy way (in my opinion).
Server: Configuring Apache HTTPS In order to share your repository. (authorization with htaccess)
Client: Install tortoiseGIT, in order to checkout, commit, update or branch.
Basically yes. You have to set up the security stuff, which is kind of unrelated to git itself. In the other PCs, you have to define a remote repository that contains the address of the repository on your computer. Then you can push to/pull from each other's repositories.