I need to get a file from a private GitLab in a script (actually a Yocto recipe, if it matters).
Issuing: https://gitlab2server.com/api/v4/projects/53/packages/generic/paCKAGE/21.08.16/FILE.tar.xz on a browser works fine, but wget <same URL> fails with a "401 Unauthorized".
I can get around the problem with curl --header "PRIVATE_TOKEN: xxxx" ... but that means encoding my private token into a shell script which doesn't seem right.
To access a regular git repo I can use git clone git:... and it works because of the uploaded keys.
Using the equivalent scp gitlab2server.com:/api/v4/... . does not work because "Permission denied (publickey).".
What is the right way to do this?
Ideally I would need to have a ssh (actually scp, of course) access using pre-shared keys to access the files. I would hate to put large binaries into the git repo just to be able to access them.
The only way to authenticate with the GitLab API (including the Package API here) is using a personal access token, or the CI_JOB_TOKEN environment variable if running within GitLab CI/CD. CI_JOB_TOKEN is one of the Predefined Variables available to every CI/CD Pipeline Job and holds a non-admin token.
Related
I have various GitHub accounts and for each account I have SSH set up. So under ~/.ssh I have a public and private key for each account.
I want to use the GitHub CLI, but I am not sure how I can tell the CLI to use a particular SSH key.
In case it is relevant, this is what I get when I run ssh-add -l:
Example Scenario
I want to run gh repo create on GitHub account B, but for some reason, the repo got created on GitHub account A. Is there a way I can tell gh what account to use?
if you have different GitHub users the gh-cli won't be very effective. as #phd commands like gh repo create require logging in via an auth token. https://cli.github.com/manual/gh_auth_login
Switching contexts between accounts (i.e. github.com/user1 and github.com/user2) def doesn't seem supported so you'd have to hack around loging in and out each time every time you switched.
But configuring which ssh key git should use can be configured easily enough in some combo of ~/.ssh/config .gitconfig and/or setting the GIT_SSH_COMMAND env var before running git commands.
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 can't get a point and understand how it works and what is necessary to do.
I have an account by GitLab and successfully generated private and public certificate in order to provide access to it. I done all steps as describes the https://gitlab.com/help/ssh/README#generating-a-new-ssh-key-pair . Now i decided to create a new project and synchronize the state between gitLab project and one i created local by me. Because i have access to machine, which i used to create both certificate, i simply copied the public key from one machine (located in ~/.ssh folder) to current machine i am working in (in ~/.ssh folder). But it doesn't take any effect. I can't even execute the git clone command.
~> git clone git#gitlab.com:[myUser]/[myProject].git
Cloning into 'gate-controller'...
git#gitlab.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
i tried to figure out the reason and executed
~> ssh -vT git#gitlab.com
but to be a honest i can't interpret that response. I don't see in response any reference to my public keys file in ssh folder.
Could you please support me to solved the issue and understand, what is the problem ?
many thanks in advance
UPDATE:
You need the private key on any machine you're attempting to pull/push from. When authenticating with a service that has your public key (which any git service like Github, Gitlab, etc. will have) you need to use your private key when authenticating.
You can read more about ssh (which git uses when you don't use HTTPS auth) and PKI (Public Key Infrastructure) here https://www.ssh.com/pki/
I run my own Conan server and want to automatically upload packages generated by CI. When I use conan upload it prompts me for a username and password. Is there a way to automate this process?
Yes, therea are a couple of ways to do it:
Using the command conan user myuser -p mypassword you can "log-in" into the remote, so the local cache will store a temporary token to authenticate against the server, and subsequent commands will not require it. Note that this token can expire, check the docs (e.g. for conan_server). Also, if you are managing more remotes, there is a login per remote (add -r=myremote to the above for each one
There are environment variables you can use for this CONAN_LOGIN_USERNAME, CONAN_PASSWORD and with using _REMOTENAME for different remotes. Have a look here in the docs. This is probably the way to go for CI, so the password is not plain text in the CI scripts. Some CI services will allow for encripted variables in the configuration. Furthermore, these variables allow automatically log-in in case of expired tokens, which can happen if they are set to short times, and the builds are very long.
is there any way to provide username and password for git pull as command line arguments? in svn there was something like:
svn up --no-auth-cache --username $SVN_USER --password $SVN_PASSWORD
Is there any equivalent of this in git? I can't store the credentials on the filesystem.
Basically, I have a script running build for multiple correlated projects. Because the script is on a shared server and is to be run by different users, I can't store the credentials on the server. I don't want to prompt the user, because the script fetches data from multiple SVN/GIT repositories with single username/pass so I want to read the credentials once via the script and then pass them to git pull or svn up commands
If you're using HTTPS, a solution might be in this answer:
The not secure way is to include credentials in the url you're pulling, https://user:password#server.com/path/to/repo. Apparently, your credentials end up as plain text in the .git folder and/or in log files.
The secure way is to configure a "credential helper" in git. Then it will remember the credentials once they're used. It will store the credentials securely on the machine, but if you use the system-wide configuration they will apply to all users. For example, with msysgit on Windows I'd use the wincred helper: git config --system credential.helper wincred. My understanding is that --system turns the credential helper on for all repositories and all users on the system, so you'll have to decide if this is okay for your server. Disclaimer: I've only used --global before.
I haven't seen better options for your situation, but some of the real git gurus might chime in.