For example I'd like to see this as a feature if it does not already exist.
Hence my question.
This should be tracked with gitlab-ce issue 18601, but for a private GitLab server, not necessarily gitlab.com.
See commit cfd5870
When you choose to allow only one of the protocols, a couple of things will happen:
The project page will only show the allowed protocol's URL, with no option to
change it.
A tooltip will be shown when you hover over the URL's protocol, if an action
on the user's part is required, e.g. adding an SSH key, or setting a password.
Related
So, I am new to the GitLab server. Now, what I want to achieve is this:
Allow access to repositories only on certain ssh-keys. There are a limited no of machines and a limited no of users, so if a user adds an ssh-key outside these sets of keys, the repo should not clone there. Because my team size is small, I am okay if I only add those public keys to the account.
I am fine with the idea of ssh access but currently, as an admin, I lose the freedom to conveniently track or choose which all ssh-keys can access my repo. Can I disable users from adding ssh keys?
Is there any other way to ensure this? Would instead of having ssh enabled access HTTPS with whitelisting IP-enabled access work?
GitLab was, in the beginning (2011) based upon gitolite, but switched to its own mechanism in 2013.
Nowadays, it is best to declare a GitLab project private and add users to said project: that way you won't have to manage SSH or HTTPS access: any user who is not part of that project won't be able to see it/clone it (HTTPS or SSH).
In other words, repository access is no longer based on SSH keys (not for years), but is based on project visibility.
The OP adds:
even if a user is part of a project, he should only be able to clone the project on certain remote machines.
That is not a Git or GitLab feature, which means you need:
to restrict Git protocols on GitLab to SSH only
change the gitlab-shell SSH forced command script in order to allow commands only coming from some IPs
There is access to group by IP address restriction feature, since GitLab 12.0 (June 2019), but... only in GitLab Ultimate (meaning: "not free").
I have Tortoisehg set up with a clone of a remote repository on Bitbucket, using https protocol. I turned on the mercurial_keyring extension, and it took care of password handling just fine. Until one day it didn't. Every time I commit now, on push-after-commit it pops up and asks me for a password.
I carefully changed the password on the server, and started typing in that password when asked. IT DOESN'T HELP! It doesn't accept that password.
I hit cancel when asked for the password. Then I go and press the Push green arrow button at the top right of the screen. After asking for confirmation – IT GOES! No password required!
There are three computers that connect to this particular Bitbucket repository. For a while two of the three were working fine without asking a password. Then another one started asking! And then a third popped up asking for something different: "You need to identify yourself to the server." Once again, cancel, use the Push button, works fine!
I am so confused. Has anyone seen this, has anyone fixed it?
BTW, the remote repository is nowhere mentioned in my tortoisehg settings, but it is in my hgrc file:
[paths]
default = https://joymaker3#bitbucket.org/joymaker3/my-repo-name
I yjink, you have to re-read at least section 3.2. "Repository configuration (HTTP)" of extension wiki and check related settings of all repos:
good (full) URL in [paths]
only needed data (if needed) in [auth] (no password for configured remote repository)
you can also enable debug in TortoiseHG and inspect output on failed push
I am trying to add my SSH ID to bitbucket from my newly installed ArchLinux setup. The instructions for adding my id to bitbucket involve using my browser and copy/paste the key. I am not using a GUI but don't know what the command is to push public keys from commandline to bitbucket. How do I manage this?
You could try to use the links command line browser, although it doesn't seem installed by default. Of course you may want to get the ID into a clipboard of sorts if you don't want to type it over.
If the posting the ID doesn't require difficult pages and settings you may be able to implement this using httpie - which does seem to be installed.
We have a 'master' Mercurial server on our network that we use for a local staging box. Our team does all of our pushes and pulls to/from this one box. I'm having trouble with the implementation I'm using, but I'm also second guessing whether what I want to do is even a good idea...
We also want to start using BitBucket, but only as a secondary server. I'd like to use a hook to automatically push to Bitbucket, but I can't get it working right...
Here's the HGRC from the 'master' repo:
[hooks]
changegroup =
changegroup.update = hg update
changegroup.bitbucket = hg push ssh://hg#bitbucket.org/account/repo
If I manually fire off the above push, everything works perfectly. However, as a hook it fails:
warning: changegroup.bitbucket hook exited with status 255
I followed this guide to get SSH working: Set up SSH for Git and Mercurial on Mac OSX/Linux
I get my keys generated, I run ssh-agent, and I ssh-add the key. But ssh-agent doesn't seem to be doing anything, and as soon as I exit the SSH session it seems to leave memory. Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password. I thought the whole point of this was for it not to do that?
But taking a step back, maybe this is a terrible idea to being with. If I give my public key to Bitbucket wouldn't that theoretically mean if someone got a hold of it, they could SSH in to my box without a password?
And if so, what alternative do I have to forward commits to bitbucket? I'd rather not use HTTPS because it would require putting our bitbucket password as plain/text in the .hg/hgrc file...
Maybe there's some more obvious way to do this that I'm missing? For the developers, I'd rather keep things the way they are now (everyone push to master) instead of reconfiguring everyone's developer box to have a private key and to push to bitbucket instead...
As always, thanks for any help you guys can provide.
Woah, there are a lot of questions there. I'll hit a few of 'em:
But ssh-agent doesn't seem to be doing anything, and as soon as I exit the SSH session it seems to leave memory.
You're correct. ssh-agent is for interactive sessions, not for automation. In most usages when you log out it's killed, but even if that weren't the case it wouldn't be working as you imagine because when someone does that hg push they're running a new, non-interactive session that wouldn't have access to the ssh-agent anyway
Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password.
Testing it out like that isn't valid. That's saying "I want to log into an interactive session at bitbucket with the username hg", but that's not what they authorize you to do. If you send them your public key they let you login as the user hg only for the purposes of doing hg non-interactive commands.
Additionally, when I test it out with ssh -Tv hg#bitbucket.org it prompts me for my password.
No, public keys are meant to be public -- you can list anyone's on github for example. The public key just says "anyone who has the private key that matches this is authorized to...", so any site that wants your private key are crooks, but any site that wants you public key is just offering you a way to use something better than a password.
One thing you may be missing about hooks is "who" the hook runs as. When people are pushing to your "centralish" repo over ssh that the hook is being run as their unix user, and if they're pushing over http the hook is being run as the web server's user.
If you had:
a private ssh key with no password on it
the public key matching that private key setup on bitbucket
the unix user running the hook using that private key for access to bitbucket.org
then what you're trying to do would work.
I had a working instance of Gitlab until a few weeks ago, when we had to move all the user directories to another disk b/c of resource constraints. I've gone through and fixed all the paths that I could find, and so now my gitlab instance is up and running again. Git appears to be working, and I pass the gitlab self-diagnostic test.
However, from a remote client that's previously worked, I get prompted to provide the git user's password, which suggests an ssh problem.
Looking in my .gitolite stuff (conf/gitolite.conf & the keydir), things look in order. My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
EDIT: gitolite public keys were in the .ssh/authorized_keys file and the protections were as created by gitolite setup.
What am I missing?
My public key is in the keydir, and the rights are assigned in the gitolite.conf correctly.
This isn't enough.
For ssh to not ask you for a password, you need to check if your ~gitlab/.ssh/authorized_keys is complete (with the gitolite public keys in it, and with the right protections)
Check out the gitolite setup command (for gitolite V3).