I use the Git on my workplace and company policy doesn't allow me to store passwords in unsecure way. Is there any better option than using git config credential.helper store for storing password to the Git server?
P.S. Can't use key-authentication as it's not allowed on our server.
git config credential.helper store is not very secure; as it said in documentation:
Using this helper will store your passwords unencrypted on disk,
protected only by filesystem permissions
The ~/.git-credentials file will have its filesystem permissions set to prevent other users on the system from reading it, but will not be encrypted or otherwise protected.
So it stores your password as is. Git allows to use your keychain git config --global credential.helper osxkeychain for OSX, so it seems to be more secure. For Linux system you may use git config credential.helper cache, which stores passwords in your memory. Or you can write your own as it said in git help credentials:
You can write your own custom helpers to interface with any system in
which you keep credentials. See the documentation for Git's
credentials API for details
Besides, #VonC pointed to the cross-platform GPG-based solution. See also this question about .netrc file.
There is also gnome-keyring helper for Linux (thanks to #jazakmeister for advice)
Related
I am a new programmer, and also still a "noob" using Debian based distributions and Linux in general. Every time I push to my GitHub repository as u know, I have to write username and password which is my GitHub token, I have the token stored in a file and I have to enter the file copy the token and use it, and it's a bit annoying, I know it's possible to store commands in variables to make shell use faster, is there some sort of way to do the same with my token? or which would be a good practice to do so?
Thanks in advance for your time.
You can cache your username/password with this command:
git config --global credential.helper 'cache --timeout=secs'
where secs (seconds) defaults to 900 (15 minutes).
I would suggest using SSH keys which you can find more information about here. When authenticating using SSH keys you don't have to type in your password manually.
A few things that would change would be that you should select the SSH option instead when you're going to clone your repository.
I believe the following command can change this configuration for repos that you've already cloned using HTTPS:
git remote set-url origin git#github.com:<username>/<repository-name>
I am creating a build script for a project using Grunt and I want to commit->tag->push to a remote server, but I do not know how to enter credentials for Bitbucket when they are asked for during the git push. The docs for grunt-git on https://www.npmjs.org/package/grunt-git do not seem to address this issue. The credentials (just a password) would be read from a config file stored elsewhere and then, ideally, given when asked for.
I was thinking perhaps I could use grunt-shell to address this, but even then I am not sure. Upon further thought, it seems that maybe I should just use grunt to do the git commit and git tag commands, then leave it to the CI server software (in this case Jenkins) to handle the credentials and pushing to remote.
So my question is really twofold:
1) Is it possible to give the credentials when they are requested in this case? if so, how?
2) Would it be a better solution (better practice/easier) to simply leave this responsibility to the CI server (Jenkins)?
Thanks.
1) Is it possible to give the credentials when they are requested in
this case? if so, how?
If you add your SSH key to Bitbucket and given that when you generated the SSH key you didn't enter a password, then you won't be prompted for any credentials when you try to push.
2) Would it be a better solution (better practice/easier) to simply
leave this responsibility to the CI server (Jenkins)?
Jenkins uses its own SSH key, and if it's passwordless it can run a build that pushes to any host in which you imported the Jenkins key without credentials.
It's usually the job of the CI server to handle this, not the build tool. But if all you need at the moment is to bypass the password on your local machine, generate a passwordless SSH key, or try something like SSH Agent.
I just uploaded my local svn file repository to an svn host. I notice that when checking out the code to my local (Linux) computer I have to provide my username and password (as expected) but subsequent operations (checkout, commit, log, etc.) does not require any authentication, so I take it that after initial login I stay logged in for some time.
My questions related to this are:
How long do I stay logged in like this?
What would trigger my access to the repository to expire?
Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
I'm running svn 1.7.9 on Ubuntu 13.10 Linux.
Thanks!
1) How long do I stay logged in like this?
You are not logged in. Your authentication tokens are saved somewhere under ~/.subversion/auth.
2) What would trigger my access to the repository to expire?
If you remove the file under ~/.subversion/auth which stores your password for the particular repository, then you will have to reenter the password again.
3) Can I manage the expiration time, and if so, is it done server side, or in my local subversion configuration?
That really depends on how authentication is configured on the server side.
Btw, you can prevent Subversion from saving your authentication tokens if you checkout using --no-auth-cache.
UPDATE
There is a lot more to this, as #BenReser points out:
Realize that the password is not necessarily stored under ~/.subversion/auth. We support a variety of platform specific credential storage (Windows Crypto API, OS X Keychain) and even in 1.8 GPG Agent. The GPG Agent case would behave somewhat like what he's envisioning, where the password is cached only for a certain amount of time, which he could configure. There is also NTLM/Kerberos support that may behave like a single sign on as well. So frankly it's really hard to answer this question without more details about his configuration.
Every time I commit a file in svn I get the following message:
ATTENTION! Your password for authentication realm:
http://domainname.com:80 “domainname.com”
can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.
You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'.
Store password unencrypted (yes/no)? no
I don't want this authentication; how can I get rid of this warning?
You are not storing the password in Subversion because you answered no to the question whether or not you want to store this password.
I take it you want to eliminate this error warning message entirely. There are two ways to handle that:
The easy, but hard way: You can specify svn --no-auth-cache each and every time you a Subversion command. It's easy to do since it requires no real action on your part. It's hard because you have to do this almost every time you use a Subversion command (especially one that touches the repository like checkout and commit).
The hard, but easy way: You can modify your user's Subversion configuration not to ask if you want to store this information. (BTW, why are you running as root? You like living life on the edge? Better off running as a user and configure sudo to allow you to do the root stuff you need. That way, you can track who's doing what, and you don't do something that could accidentally bring the server down. In fact, many Unix/Linux systems by default no longer allow a user to sign in as root. You have to do sudo). This is hard because you have to do something, but easy because once you do it, you don't have to do anything again.
You have the name of the file that you need to edit (/root/.subversion/servers). Look for the [global] section and look for the line # store-passwords = no and remove the # from the beginning of the line. You can also do the same for the # store-plaintext-passwords = no line and the # store-auth-cred = no line. While, you're at it, you can also delete the files under the auth directory which is where Subversion stores its credentials. This will completely eliminate already stored passwords. More information can be found in the on line Red Bean Subversion manual.
Now, when you do a Subversion command that touches the repository, it'll ask you for a user name and password and won't ask if you want to store them.
You copied the full warning message here. Reading it instead of just copy/pasting it would answer your question:
you can avoid future appearances of
this warning by setting the value of
the 'store-plaintext-passwords' option
to either 'yes' or 'no' in
'/root/.subversion/servers'.
The subversion client is only asking for authentication because the server requires it. To get rid of the authentication requirement, you'll have to change the server's configuration (e.g., in Apache, get rid of AuthType, AuthName, and AuthUserFile). You can use other authentication methods which do not require passwords (for example, client certificates).
If you just want to get rid of the save password unencrypted prompt, you can set store-plaintext-passwords=off (by editing ~/.subversion/config) or you can make encrypted passwords work by getting (on Unices) the GNOME keyring or KDE wallet running. On Windows, SVN should automatically use built-in NTFS encryption; on Mac OS X, the Keyring. See the Client Credentials section of the SVN Manual for further details.
You could also encrypt your home directory on Unix. Then the credentials would be encrypted as well (but of course available to any program running as you or root while you're logged in, similar to the NTFS encryption).
If you don't want SVN to store passwords at all, encrypted or not, set store-passwords=no in the SVN config file.
How is the best way I can create a jailed user on a Linux machine to be used solely for a git repository?
git-shell is a restricted shell that you can use for this purpose.
If you make set a user's login shell to git-shell then he can only run a limited set of server-side git helper functions which enable remote git over ssh usage but don't permit a normal log in.
Also look in to gitosis. In particular, it sets some parameters in .ssh/authorized_keys which prevent port forwarding, etc:
command="gitosis-serve user#host",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa AAAA....
Even if you do not use gitosis, you may want to include the restrictive options.