Store GitHub token in a shell variable Linux Debian - linux

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>

Related

Git GPG password in keyring

I'm using git with GnuPG signing. Each time I want to sign a commit I have to provide my GnuPG key password.
Is it possible to make git take advantage of some system-wide keyring, like gnome-keyring? I can't seem to find any documentation on that, or even any thread on this in the web. Perhaps there is some solution I'm not aware of, that is not popular enough to be easy to google.
There are probably some GUI tools that can do that for me, but I'm not interested in those, I mostly use git from console, sometimes from IntelliJ-based IDEs, which just invoke the system git binary. Having a system-side solution will allow me to use git config --global commit.gpgsign true with these IDEs (and cli).
Copied from https://superuser.com/questions/624343/keep-gnupg-credentials-cached-for-entire-user-session
Up to GnuPG 2
The user configuration (in ~/.gnupg/gpg-agent.conf) can only define
the default and maximum caching duration; it can't be disabled.
The default-cache-ttl option sets the timeout (in seconds) after the
last GnuPG activity (so it resets if you use it), the
maximum-cache-ttl option set the timespan (in seconds) it caches
after entering your password. The default value is 7200 (2 hours) for
both.
Set it to a year or so – say, 34560000 seconds (400 days) – and you
should be fine:
default-cache-ttl 34560000
maximum-cache-ttl 34560000
But for this change to take effect, you need to end the session by
restarting gpg-agent.
If you want to limit to your session length, you'd need to kill the
daemon at logout. This is very different between operating systems, so
I'm referring to another question/answer containing hints for
different
systems.
You could also restart the gpg-agent during login, but this does not
limit caching time to the session length, but logins of a user. Decide
yourself if this is a problem in your case.
GnuPG 2.1 and above
In GnuPG 2.1 and above, the maximum-cache-ttl option was renamed to
max-cache-ttl without further changes.
I see you use Fedora, in version 29, all I had to do was:
git config --global gpg.program gpg2
And it uses the Gnome Keychain (seahorse).

How secure is storing password with Git?

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)

how to get grunt to input git/bitbucket credentials on push to remote

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.

Making scripte answering svn+ssh passkey

I have a shell scripte that i have to configure for updating some svn repository set up with crontab in order to backup the repository on an other machine.
The thing is one of the repository is protected with an key which is password protected.
I'd like to make the scripte automatically answering the question, and i don't know how to do this.
I already tried the "yes | svn co svn+ssh... " and it doesn't seems to be working.
Is there a way to make the scripte answering it, or simply juste stop svn from asking the password by storing it somewhere?
Thanks for your time.
That would only be possible if you have launched first an ssh-agent.
See for instance "svn + ssh without password from command line?", and this tutorial.
The first connection will ask for the passphrase and register it.
The other connections won't ask for the passphrase at all.

How to create a restricted SSH account for a GIT repository?

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.

Resources