I just installed the newest Omnibus Gitlab in CentOS 7. I have added my public key to my account but gitlab keeps prompting me for a password every time I try to connect using ssh, like ssh git#mygitlab.com. The git home folder is /var/opt/gitlab.
Here are the various things that I've done:
I have checked that write to authorized_keys is checked in the admin area -> settings -> network
I have chmod the relevant folders and authorized_keys file. 0700 for home, 0711 for .ssh and 0600 for authorized_key file
I have deleted and re-created the authorized_keys file
I have checked various gitlab log files and nothing shows any clue
I have restarted and reconfigured using gitlab-ctl and restarted the computer
You may want to configure Fast lookup of authorized SSH keys in the database.
This should solve the problem you're facing and it won't require manual rebuild of authorized_keys file whenever someone adds or removes SSH/deploy key in GitLab.
Edit: This bug was introduced with GitLab 12.9. It was confirmed and it should be resolved with 12.9.1 patch release, which is expected to be released soon.
I have solved half of the problem although I don't know what the root cause was. I looked into this page docs.https://docs.gitlab.com/ee/administration/raketasks/maintenance.html#rebuild-authorized_keys-fileabout rebuilding authorized_keys using this command: sudo gitlab-rake gitlab:shell:setup, and gitlab rebuild the key and created authorized_keys.lock in the .ssh folder. Now, I can ssh -T git#mygitlab.com, although the user name was changed to Anonymous, now I'm facing another problem. When I try to clone or push, gitlab said the project can't be found. :( . I guess I'll have to look for it more.
EDIT: somehow by luck, I managed to solve this by creating a new user, added the ssh key for that user and run gitlab-rake gitlab:shell:setup again to make Gitlab added the public key to authorized_keys file.
What a mess in Gitlab and I see ton of issues regarding this authorized_keys and ssh from a long long time ago (5 - 6 years ago and still similar issue) and it still happens now.
Related
I've installed GitLab on Google Compute Engine using "Click to Deploy" from the project interface. The deployment is successful after a few minutes. I can SSH into the instance, and muck around with it as expected.
I can also log in to GitLab using the web interface, and add SSH keys to my profile. So far, so good. However, when I attempt to push or pull to a new example repository, I receive this message:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I've removed my local SSH config so it doesn't interfere. Do I need to setup an SSH tunnel of some sort? What am I missing?
UPDATE: Wiping out my local ~/.ssh folder, and regenerating an SSH key (which I've added to my profile in GitLab) produces the following error:
Received disconnect from {GITLAB_IP_ADDRESS}: 2: Too many authentication failures for git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
UPDATE 2: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
You need to create an SSH tunnel to communicate with GitLab.
1. Log into your development server as your user, and create a key.
ssh-keygen -t rsa
Follow the steps, and create a passcode (that you can remember) as you'd need this to pull and push code from/to GitLab.
2. Now that you've created your key, we can copy it;
cat id_rsa.pub
Copy the output of that command (including ssh-rsa), and add it to your GitLab profile. (http://my-gitlab-server.com/profile/keys/new).
3. Ensure you have the correct privilege to the project(s)
Ensure you are at role developer at the very least. (Screengrab of roles: http://i.stack.imgur.com/DSSvl.jpg)
4. Now, copy the project link
Go into your project, and find the SSH link in the top right;
5. Now back to your development server
Navigate to your directory where you'd like to work, and run the following;
$ git init
$ git remote add origin <<project_url>>
$ git fetch
Where <<project_url>> is the link we copied in step 4.
You will be prompted your password (this is your ssh key password, not your server password) and to add the host to your known_hosts file. After that, the project will start to download and you can enjoy development.
I did these steps on a CentOS 6.4 machine with Digital Ocean. But they shouldn't differ from using Google CE.
Edit
Quote from Marty Penner answer as per this comment
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Solved it! Thanks to #sxleixer and #Alexander Wenzowski for figuring this out.
Apparently, SELinux was interfering with a non-standard location for the .ssh directory. I needed to run the following commands on the Compute Engine instance:
sudo yum -y install policycoreutils-python # Install the `semanage` tool
sudo semanage fcontext -a -t ssh_home_t "/var/opt/gitlab/.ssh/authorized_keys" # Allow the nonstandard ssh_home_t
See the full thread here:
Google Cloud Engine. Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
UPDATE: It seems GitLab may already have a solution: run sudo gitlab-ctl reconfigure. See here: https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/README.md#git-ssh-access-stops-working-on-selinux-enabled-systems
In my situation the git user wasn´t set up completely. If you get in your log files messages like "User git not allowed because account is locked" (Under Centos or Redhat it´s /var/log/secure) than you simply need to activate the user via "passwd -d git"
I have two CentOS servers that are set up the same. I created a git repo on server A and pushed it to github. I then cloned the repo on server B. At first, all seemed to be in order. I could commit on either server, push to the remote, and the pull on to the other server.
The problem is that my co-workers now cannot push or pull on server B (they can run git status or commit). Strangely, this applies to ALL repos on server B, not just the one I cloned. Here is the error they see:
ERROR: Repository not found.
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I checked that they are in the collaborators lists (both as owners and on the team assigned to the repo).
I also tried changing to the root user and cloning the repo again--as root I received the same error as above. The global .gitconfig does not reference my user or key, and the local .git/config files are set to use SSH (git#github.com).
What would cause this error to happen all users but one? Where else should I be looking?
Add '-v' to your git command as you run it to get more verbose output, that should tell you what's wrong.
I did resolve this issue. I found the problem by running ssh -T -vvv git#github.com which showed different keys being used for my user vs. the other users on the server. The key being used generally was not tied to a user in our github account. The fix:
Generated a new SSH key
Added key to shared user on github account
Updated .ssh/config to use the new key when accessing github.com
I am not certain how the SSH key got messed up, because it worked before. But this fixed it.
I installed Gitlab on my Ubuntu successfully(gitlab.domain.com), on a client PC I installed Git (windows 7), then run Git Bash to generate SSH keys with command: ssh-keygen -t rsa -C "username#domain.com" to create private/public keys on C:\Users\AccountName.ssh
Then, add public key to profile on installed gitlab. Then can clone/push on Git Bash.
However, I can not reproduce this on other PCs, I tried some PCs, created new users, new ssh keys...
but always encounter that error "The remote end hung up unexpectedly", sometimes can clone but also get that error when pushing.
I can only clone/push on first PC. I'm so confused, don't know what I missed. I'm trying to get my team on Git
Thanks a lot for any advice
Make sure you are pointing it at the correct git server. Also - login on your Jenkins server (Under the jenkins user) and ssh to git#your-git-server and make sure to select 'yes' to add the server to your known hosts.
I had the same error and it was an access-level problem :
my user only had guest access to my project so it wasn't able to clone it. I changed the access level to developper and it solved my problem
I had a gitolite pre-g2 repository I am attempting to get going on g3.
I copied over the entire repositories folder, and started with a clean g3 conf file, and removed all the gl-perms files to have a clean slate. I am trying to get a couple repos up and running with per-repo permissions.
Specifically I have my admin access keys and can clone and push the repo. This is defined the gitolite.conf as:
#admin = nikolaj
repo #all
RW+ = #admin
Then for the individual repo, I made sure my name (nikolaj) was in the gl-creator file, and removed the old gl-perms file.
I then try to run
ssh git#myserver perms my/repo
and I get
FATAL: sorry you are not authorised
Any help on how I can go about debugging this is greatly appreciated!
Make sure you followed the migration guide and did preset your gitolite.rc file
If you don't preset the rc (in this case, by commenting out the 'ssh-authkeys' line) before running gitolite setup, your ~/.ssh/authorized_keys file will get clobbered.
In your case, you did get a new gitolite.rc file, but still check if your ~/.ssh/authorized_keys is still intact (with a forced-command using nikolaj as parameter)
I installed gitosis on my Ubuntu 10.4 Server via
apt-get install gitosis
Then I initialized the admin repository with
sudo -H -u gitosis gitosis-init < nameOfThePublicKeyFile
After this I thought that it the admin repository is only clonable for clients that offer the private key that fits to the public key file of the repository. So just to be sure, I tested if it is possible to clone the repository without the private key or with a false private key. Unfortunately and surprisingly it worked.
I tested this with tortois git on windows.
Therefore my question is:
How can I secure my repositories, so that they can only be cloned if I provide the correct private key.
Did I skip an important step in the installation process or anything?
Thanks for any help!
I think I found the error and it has nothing to do with gitosis.
I found out that my tortoisgit client on windows somehow caches the correct private key file of a git connection if it cloned a repository succesfully once. Even if I provide a wrong keyfile afterwards.(I don't know where it saves it but I saw it in the config file that is created by tortoisgit when a repository is cloned.)
I tried to clone my repository with with another windows computer, just to be sure, that is is only a caching problem. And voila this other computer that never saw my private key file could not clone the repository.
It is always useful, when the GUI fails (here TortoiseGit) to revert to the CLI (msysgit or git itself) to see if the issue persists.
You saw that it might be related to an authentication cache problem within TortoiseGit, and bug 659 does illustrate that cache problem.
The other option would be trying to use a 'config' ssh address, ie an ssh address based on a ssh config file (where you can reference explicitly the name of the private key to use for that connection).
See as an example "NBGit to remote host with ssh" or "git + assembla + multiple ssh keys/multiple computers".