This one is rather complicated to describe. I have two github accounts, I will refer to them as github A and B.
I had created a local repo X and tried to connect it to a new remote repo I created on github account A. However, my default github login credetials were set for my github account B. I went through this tutorial and was able to add a second key created in my .ssh to allow me access to acct. A at will. This method worked and allowed me to add the new remote repo on github account A to my local repo X. I could then push origin to master just fine.
I then made a clone of the same repo X on github account A and placed it in a new local location (same drive, different folder) which I will refer to as local repo Y. I then tried to push changes to the same remote repo on github A and it denies me saying I'm trying to access using my username for my remote github B account.
I tried re-adding the remote url via the same special .ssh key previously created for repo X and use it for the local repo Y but it says it already exists.
I'm looking for a simple solution here, hopefully one exists. I would appreciate your help on this.
You can test what actual key is used with:
ssh -Tv <yourSSHConfigEntry>
Make sure to use an ssh URL like yourSSHConfigEntry:/ (no need to prefix it with git#: the User should be in your ~/.ssh/config file)
The idea is: your SSH config file should use the right private key, whose public key has been registered to the right GitHub account.
Check the remote URL: git remote -v. If it starts with git#github.com, it won't use the ssh config entry.
Type:
git remote set-url origin <my-github-acct-A>:<user>/<repo>
That will use the SSH config entry, and make sure the User in it is "git".
I'm pretty sure the issues you're running into are a result of managing multiple accounts on the same computer, regardless of the repos being duplicates.
If you haven't already, I'd suggest you take a look at the very detailed answers provided here.
I have been through this trouble many times and have resolved it by setting the ssh config rules or by enforcing the ssh-agent to have the correct ssh key alone.
I have documented the entire process and Freecodecamp published the article.
Here's the link! Hope this will help whenever you come across this use case. :)
Related
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.
I'm trying to create an automated build on Docker Hub from a Github private repository.
I linked my Github account with my Docker Hub account.
I verified that the deploy keys provided by Docker Hub are created in my Github repository
But I still have an error. I'm not sure if it's related to SSH keys or gitmodules.
Here is the log I get (in Build Details tab in my Docker Hub repo) :
Starting to clone
Cloning into 'bsntx4mjvrqncsdvzcn7tqp'...
Warning: Permanently added the RSA host key for IP address 'XXX.XX.XX.XX' to the list of known hosts.
No submodule mapping found in .gitmodules for path 'vendor/bundle/ruby/2.1.0/bundler/gems/logan-3722sdf9a9db5'
please ensure the correct public key is added to the list of trusted keys for this repository and the remote branch exists. (1)
Does anyone has the same error ?
My solution : I have solved my problem by removing the file vendor/bundle/ruby/2.1.0/bundler/gems/logan-3722sdf9a9db5 in my github repo. So the error about the public keys has nothing to do with it.
The issue is not with the key.
I don't know the exact issue. You can use the following command to sort the issue out.
git submodule update --init
The output of the command will be passed to
git rm --cached {{output}}
Push the commit.
I can't comment, so I'm posting this as an "answer" instead (sorry!)
I have the same issue with Bitbucket, it fails to fetch from my submodule which is included in my main repo. I haven't been able to fix this issue yet. I even bough a paid subscription and added an automated build in hub.docker, hoping that would fix it, but nope..
Starting to clone
Cloning into 'bokyrk3hkhspby5smhf6kby'...
Warning: Permanently added the RSA host key for IP address 'xxx.xxx.xxx' to the list of known hosts.
Submodule 'lib/shared' (https://xxx#bitbucket.org/xxx/xxx_sharedlibs.git) registered for path 'lib/shared'
Cloning into 'lib/shared'...
fatal: could not read Password for 'https://xxx#bitbucket.org': No such device or address
Clone of 'https://xxx#bitbucket.org/xxx/xxx_sharedlibs.git' into submodule path 'lib/shared' failed
please ensure the correct public key is added to the list of trusted keys for this repository and the remote branch exists. (1)
Following procedure followed by me made it work:
Added my private key to local ssh through git bash.
Added my public SSH key to github.
This ssh key was already available in my dockerhub.
So, I linked another public dockerhub userid (where automated build was successful) as a collaborator to this private automated build.
For work with private repo, you should add ssh key from Docker Hub (showing on add auto build) to your github ssh keys.
When the automated build fails the orange alert on the top of the build details can be a bit deluding:
Build failed: please ensure the correct public key is added to the
list of trusted keys for this repository and the remote branch exists.
(128)
Even when you have set up you ssh keys this message always displays. You need to look at your Logs at the bottom of the build details to see more information if you know that you have set up your ssh keys for a private repo already.
For example your logs might say:
fatal: no submodule mapping found in .gitmodules for path
'my-app/my-blog'
or maybe it could be
Dockerfile not found at ./my-app/Dockerfile
in your case you had a problem related to having the file vendor/bundle/ruby/2.1.0/bundler/gems/logan-3722sdf9a9db5 in your solution which needed to be removed.
When I try to push my project on Github, I have to sign in every time with my Github account before the push. And I don't understand why, on certain projects I don't need to do this, only on one project.
MacBook-Pro-Firstname:ProjectName firstname$ git push origin master
Username for 'https://github.com': email#gmail.com
Password for 'https://email#gmail.com#gmail.com#github.com': *******
How can I remove the sign in process?
GitHub offers two different authentication methods for read/write access. The first, which you appear to be using, is the HTTPS method and requires username/password authentication. The other way is via SSH which uses public/private key pairs to authenticate rather than a username/password combination.
To change the URL of the repository to the SSH version, you can use git config remote.origin.url git#github.com:username/repository.git
It sounds like you already have SSH keys generated and added to your account if you don't need to authenticate for some projects, but if you don't you can set it up via this link.
I am not entirely sure but I believe you will need to create an SSH key: https://help.github.com/articles/generating-ssh-keys
You need to set up a public SSH key with Github. See this article: https://help.github.com/articles/generating-ssh-keys
We recently moved our github from one account owner to another, and now all of the sudden when I do a git pull or any git command on the remote repo, it asks me for github username and password.
My git-config says:
[github]
user = kamilski81
token = *********
Any idea how I can stop it asking me for credentials and remember everything, does the new owner have to setup my ssh keys or something of that sort?
Following this article sorted it out for me:
https://help.github.com/articles/why-is-git-always-asking-for-my-password
git remote set-url origin git#github.com:user/repo.git
The github username and token in the gitconfig is only used for interactions with the GitHub API (for instance the hub gem and the github tool).
If you are pushing and pulling from a GitHub repository over https, then you need to specify your credentials every time, or hook into a password manager to remember the credentials for you. How to do this depends on your platform.
The easiest thing to do is to go to your github account and submit your SSH public key to your account, and then switch your github remote to push/pull over ssh instead of https.
[edit] After re-reading the question I noticed that you mentioned it was previously a GitHub repo that was just moved from one owner to another. If that's the case, and you ARE able to push and pull by specifying your credentials, it sounds to me to be one of two scenarios:
The previous remote used ssh, and GitHub has your SSH key; but when the owner changed and you updated the remote, you updated it to go over https.
The previous remote used https, but you had a password manager setup correctly to deal with your credentials, which no longer works.
After doing "remote -v"....the issue was that my remote was using an "https" remote rather than "git" remote. Changing the remote to use git rather than https solved everything.
If you execute only once git pull and Git client still asking you the credential without do the git pull for you, the problem should be because your credential is incorrect or not setup yet.
but if you get the dialog ask for credential one for each operation, it mean that your credential isn't remembered. To do that, you may use Pageant to store your SSH private key, so, everytime you do something, it will retrieve your credential from Pageant instead to asking you.
I have attempted to add a new repository to github per their usual instructions with an odd rejection...
Owner#Owner-HP ~/Bescrewed
$ git push -u origin master
ERROR: Permission to TangibleDream/Bescrewed.git denied to TangibleDream/demo_app.
fatal: The remote end hung up unexpectedly
Owner#Owner-HP ~/Bescrewed
The problem is, demo_app was my last repository. The one I'm doing presently is bescrewed and should be in no way connected to demo_app.
Has anyone had this issue before?
It might be tied to an ssh issue as described in GitHub help page:
Permission to user/repo2 denied to user/repo1
This error occurs when you attach your key as a deploy key on repo1.
You can push and pull from that repo without issue, but you won’t have access to any other repo with your key.
To solve this, remove the key from repo1’s deploy keys and attach it on your account page instead. This key will now have access to all repos your account has access to.
See Deploy Keys
What are deploy keys?
Deploy keys are ssh keys just like the ones you attach to your account to allow you to push to and pull from your repos.
The only difference is that deploy keys are designed to allow access to a single private repo.
This will allow your staging or production server to pull in from your repo
The other possibility is that somehow your 'origin' remote is incorrect (check what git remote -v returns)