I am trying to use my Yubikey to sign git commits.
I was able to create a master key with three subkeys (authentication, signing and encryption).
After I created the subkeys I moved them to my new yubikey. So on the computer I created the keys everything works fine. Meaning that I am only able to sing commits (and files) if I insert my yubikey.
However, I exported the public key of my master key and imported it on antoher machine. Now on this other machine it shows that the subkeys are stored on the computer instead of my yubikey. Furthermore, I am able to sign commits and files without having to insert my yubikey.
Does anyone of you have an idea what I did wrong?
Related
I know github has changed the code push strategy and made it a token based one, even though I haven't tried it yet, but is there a way to push the code to github by using username/password as I am using a temporary laptop and don't want to save any personal details.
I am getting the below error:
remote: Support for password authentication was removed on August 13, 2021. Please use a personal access token instead.
remote: Please see https://github.blog/2020-12-15-token-authentication-requirements-for-git-operations/ for more information.
is there a way to push the code to github by using username/password as I am using a temporary laptop and don't want to save any personal details.
You can generate a PAT just for that temporary laptop
Or you can generate an SSH key on that temporary laptop, that you will use only there, with an SSH URL.
In both instances, you can revoke (the PAT or the public registered SSH key) later on, when you no longer use that temporary laptop.
While installing some dependencies I came across this.
What security is gained when validating a download with an OpenPGP key downloaded from the same source, besides the corruption of the file?
There are several reasons for providing the key at the same source.
Trust on First Use
This concepts expects that the download source is not compromised when you access it for the first time -- for example, during development phase from some development client. Explicitly pinning the key to the one downloaded protects you from attacks on the download source during later phases, for example for unattended builds on some build server.
Fetching an Updated Copy of the Key
A key location next to the source code is very handy if you already know the fingerprint of the primary key (ie., pinned the key as discussed above), but want to update the key with respect to subkeys, certifications, user IDs without accessing key servers. Lots of enterprise build servers have very strict firewall rules set up, accessing key servers might be out of scope (but you obviously have access to the source code for building it). Also, you often want to remove access to third-party resources as they imply another source of issues like availability, ...
Especially updating subkeys is very important: a good OpenPGP practice is to have a long-lasting primary key and exchanging subkeys in given intervals, or using different subkeys for different build servers. By pinning the primary key's fingerprint and importing a fresh copy of the key each time you validate a third-party resource, you can be sure about having an up-to-date copy of the key including subkeys.
A Starting Point to Validate the Key
OpenPGP keys can have certifications by other keys on it. After importing, there is probably no trust path from other validated and trusted OpenPGP keys yet, but having the key and its certifications imported is a starting point for finding such a path. For example, developers of an open source project might certify the project key.
Fetching the unvalidated key from the source repository is a starting point for performing such a validation.
I am running Git on OSX Mavericks and have not had issues until now. What has changed is that I'm trying to use two Github accounts on different repos on the same computer.
The problem is that the osx-keychain is storing the login information from my first account. That was terrific before, but whenever I try to commit or push from my new Github account, it is defaulting to use the keychain's username and password values, and ignoring the locally-defined git config (or even global git config!) files.
I can delete my osx-keychain, and then push to the new account, but in doing so it will create a new keychain for that account, which puts me back at square one: able to push to my secondary account with the new keychain values but locked out of my primary account.
So I'm stuck in an "either-or" situation, and I'm really hoping there's a "both" solution. Any help?
P.S. I have tried this solution, and it did not work, as the osx-keychain appeared to override the SSH Identity functionality
If you are using https url, then the solution you mention wouldn't have any effect: it is for multiple ssh keys.
Regarding https, this question mentions a few solutions, including:
By default gitcredentials only considers the domain name.
If you want git to consider the full path (e.g. if you have multiple GitHub accounts), set the useHttpPath variable to true, as described at gitcredentials.
Note that changing this setting will ask your credentials again for each URL.
By default, Git does not consider the "path" component of an http URL to be worth matching via external helpers.
This means that a credential stored for https://example.com/foo.git will also be used for https://example.com/bar.git.
If you do want to distinguish these cases, set this option to true.
Also, make sure your https url incudes your account name:
git clone https://user1#github.com/auser/aprojectX
git clone https://user2#github.com/auser/aprojectY
That will help a credential helper to known which account/password it should be looking for.
Finally, the authentication you are using for accessing a git repo hosting service has nothing to do with:
git config (--global) user.name
That last config is only for setting the author associated with your local commits.
It is not for selecting the account used to access a remote hosting website.
I am very new to coding, I have actually just started learning how to through the use of video tutorials. Anyway one of the steps along the path of learning is setting up an account on GIT and linking this account to my ruby command prompt, where all the work I do is saved onto this app.
The problem I have run into is that, for some reason, after following the instructions of both GIT and the video tutorial I am not quite able to do the following step.
git push -u origin master
the error I get is:
warning: Permanently added to the RSA host key for IP address .....
Permission denied (publickey).
My best guess is there is an issue with being an administrator or something along those lines but I do not possess the knowledge to change that at the moment.
I would like to point out here that I am a windows user, I have seen a lot of "solutions" out there which simply dont work for me as they include commands like "sudo" or others which do not exist in the windows format, well at least not on mine as I have decided not to go through Cygwin.
Any help would be appreciated. Thanks in advance to who ever tries to help!
The issue is with your SSH public key. Somehow the git server is not able to recognize you and refuse to accept the code you pushed.
SSH keys are stored in ~/.ssh/. You should make sure there's one created. If there's one, then link it with your git server account, otherwise, create one and link it.
Checkout this tutorial on creating SSH keys: https://help.github.com/articles/generating-ssh-keys#platform-windows
Weeks ago (and in a fog), I needed to make some changes to something hosted at github. I was directed by someone-who-knows-more-than-me (SWKMTM) via phone on exactly what to type in order to configure, pull down, modify, push back and then activate things. Part of this involved issuing instructions to git that said I as SWKMTM.
Now that I've had time to learn a bit about git/github (as well as to recall my github login information), I've gone back and tried to substitute my identity for SWKMTM on my client machine (a la git config --global user.name and git config --global user.email). After doing this, I can perform the same update activities as before. However, I have yet to be prompted to enter my github password (i.e., there is NO request to enter my github password). I'm assuming that something has been cached identifying me as SWKMTM (and that I must've done something in the earlier fog that involved entering SWKMTM's github password) -- either locally or by implicitly sending my SSH public key.
I've searched around in vain for .*rc files and configuration directories for anything that resembles credentials that might be associated with SWKMTM (in hopes of dispatching said credentials and forcing git to prompt for new ones). I've similarly failed to find anything at github that might tell if there is some sort of aliasing for public keys (and how it might be purged).
I've also tried the advised "git config -l" for any credential helper and have found none.
How can I force github to forget that I've been masquerading as SWKMTM?
[sidenote: this is on MacOS with no indication in config files that credential-osxkeychain is used. Only after using GIT_TRACE=1 on a push was it obvious where the credentialing was stored.]
user.name and user.email have nothing to do with credentials, they are just strings that are put into each commit you make to store your authorship information.
Git normally authenticates you via SSH, so you have to either copy your SSH private key from the other machine to your new client, or create a new key pair and add the public part to your github profile.
OK, after extensive discussion in the chat it turns out that Git was using the osxkeychain credential helper which provided previously stored credentials.
Remove your stored credentials from your OSX keychain or disable the crendential helper (credential.helper config option) in Git to be prompted for authentication again.