Best practices developing with git and github

[hoglet]

That's not right, surely? What am I doing wrong?

Is this happening with your ADFS repository fork?

It could be that the way you are cloning your fork is incorrect.

What does the ADFS/.git/config file contain?

Code: Select all

cat ADFS/.git/config

Dave

[BeebMaster]

Yes, with the ADFS fork:

Code: Select all

cat ADFS/.git/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = false
	logallrefupdates = true
[remote "origin"]
	url = git@github.com:beebmaster/ADFS.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master

[sweh]

FWIW I have a specific key for git, and I set ~/.ssh/config to always use it

Code: Select all

Host github.com
  User git
  IdentityFile ~/.ssh/git
  IdentitiesOnly yes
  ForwardAgent no

Note that Github will delete an ssh key if it hasn't been used for a year; https://docs.github.com/en/authenticati ... g-ssh-keys

[BeebMaster]

At the moment, I am just regarding it as an inconvenience, or additional necessary step, that every time (and not very often - but certainly more frequently than at annual intervals!) I do a push, I have to first generate a new key and upload it or copy it into the security keys section of my Github online account profile. But really I would rather get it sorted properly. I read lots of online posts about it, but nothing short of starting again with a new key seemed to be the solution, and that looks to be only temporary.

Also for tidiness I have been deleting the old expired/broken/unused keys, though the first time I tried to do this, my Github account said I shouldn't do this as it may de-authenticate anything I had done with that key, so at the time I kept it. Later on, after I had to make another new key, I did delete the older ones and didn't receive the same sort of prior warning. Far as I can tell, deleting old keys hasn't broken anything.

There's been talk elsewhere about additional security measures being introduced, but I haven't had any notifications about that as far as I know. Maybe I am missing something that I should have done which is why keys don't last.

[tom_seddon]

I've never had to do anything like that, and the SSH key on my laptop is over 10 years old - so it is possible, at least in theory. I just let git use the default settings, follow the GitHub instructions to generate a SSH private key in ~/.ssh/id_rsa, and sure enough git reads it from there. I've always found this to work the same on Windows, macOS and Linux.

Is your SSH private key getting recreated periodically, for whatever reason? Possibly some automated security thing. For Git you might need to copy what sweh does, so you've got a separate key for Git. Maybe that's a good idea anyway (but for my part, I am just lazy)

--Tom

P.S. Regarding the extra security measures, which I assume refers to 2FA, this appears to be for logging in to the website only. I didn't have to do anything with my 10 year old SSH key when I activated it

[BeebMaster]

OK, well, I am hoping to do another push in the next couple of days, which it looks like will necessitate making a new key as it didn't work yesterday. So when I do that I will meticulously record all the steps involved so we can see if I have done anything wrong, or whether the new one lasts any longer.

I don't think the key is being recreated periodically, unless something is doing that automatically that I don't know about. The volume I use for Github is backed up every week. Possibly that adds an access time stamp which makes it not identical to the original key? That's the only difference over time I can think of.

[guesser]

I would suggest before you make a new key, look at your current public key (probably ~/.ssh/id_rsa.pub) and see if it's still the same as what you authorised in github.
I can't think of any logical reason for your ssh keys to be changing from one week to the next. I presume you don't use (key based) ssh for anything else or that would be constantly breaking too.

[tom_seddon]

Something you can do is ssh-keygen -l, which will print out hopefully the same SHA256 checksum for your public key as you see in the GitHub settings page. So, on my work PC, via Git Bash on Windows:

Code: Select all

$ ssh-keygen.exe -l -f ~/.ssh/id_rsa
3072 SHA256:gfKm3imUpntVHgWNMuCKTlPAlTkGCtqCBYd3Jq7lvD4 tom@nequinox (RSA)

(If ssh-keygen prints out something other than the SHA256: I don't know how to fix that.)

And then, on the GitHub website:

Code: Select all

Tom Seddon [work PC]
SHA256:gfKm3imUpntVHgWNMuCKTlPAlTkGCtqCBYd3Jq7lvD4 

So: that's a match.

Anyway, this might serve to at least give you simple yes/no answer as to whether your current SSH private key really does match the one on GitHub.

I would suggest before you make a new key, look at your current public key (probably ~/.ssh/id_rsa.pub) and see if it's still the same as what you authorised in github.

GitHub doesn't show you the actual key any more, just the SHA256.

You can do "ssh-keygen -y -e -f ~/.ssh/id_rsa" to print out the public key given your private key, so if you've got a backup of the id_rsa.pub contents you submitted then next time it fails you could check it against that.

--Tom

[guesser]

GitHub doesn't show you the actual key any more, just the SHA256.

Ah. Shows how long it is since I've had to log in and change anything then!

[hoglet]

Ah. Shows how long it is since I've had to log in and change anything then!

12 years for me!

[sweh]

For me it was a couple of months ago because a secondary account I use for NSFW purposes hadn't needed a push for 13 months and so I had to re-up the public key.

The ssh config solution is quite flexible if you ever need to deal with multiple accounts (eg if you're a contractor needing access to multiple repos from different client companies)
eg

Code: Select all

Host account2.github.com
  Hostname github.com
  User git
  IdentifyFile ~/.ssh/git_account2
  IdentitiesOnly yes
  ForwardAgent yet

Now I can do

Code: Select all

git clone -c user.name="My Account2 Name" -c user.email="My Account2 Email" git@account2.github.com:FOO/bar

and it'll use the account2 stuff with whatever name/email is needed for account2. Obviously I've scripted a wrapper for it

[BeebMaster]

As far as I remember, and according to my bash history, last time I did this:

Code: Select all

ssh-keygen -t ed25519 -C beebmaster@beebmaster.co.uk
ssh-add ../ssh.pub
ssh-add ../ssh

Dunno what the -t switch is for, but something said I should do that, so it may be wrong.

Then I opened the ssh.pub document, which came up in Open Office, and pasted its contents as a new key in the settings section of my Github account.

Then the push worked.

So now:

Code: Select all

ssh-keygen -l -f ssh
256 SHA256:ksNt0MwV3N5cAIfcVzB1qLn9v2k13PmyetWkpIzNPhU beebmaster@beebmaster.co.uk (ED25519)

And:

But still:

Code: Select all

git push origin HEAD
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Does it matter where I am? When I do the push I am in /media/GH/ADFS, but the key files are in /media/GH.

[BeebMaster]

Just in case the permissions look wrong:

Code: Select all

ls -l ssh*
-rw------- 1 ian ian 419 Aug 29 00:28 ssh
-rw------- 1 ian ian 109 Aug 29 00:28 ssh.pub

[BeebMaster]

I think I might be getting somewhere.

I looked at this, which refers to the exact error I am getting:

https://docs.github.com/en/authenticati ... -publickey

Code: Select all

ssh -vT git@github.com
OpenSSH_8.9p1 Ubuntu-3ubuntu0.3, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to github.com [140.82.121.3] port 22.
debug1: Connection established.
debug1: identity file /home/ian/.ssh/id_rsa type -1
debug1: identity file /home/ian/.ssh/id_rsa-cert type -1
debug1: identity file /home/ian/.ssh/id_ecdsa type -1
debug1: identity file /home/ian/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/ian/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/ian/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/ian/.ssh/id_ed25519 type 3
debug1: identity file /home/ian/.ssh/id_ed25519-cert type -1
debug1: identity file /home/ian/.ssh/id_ed25519_sk type -1
debug1: identity file /home/ian/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/ian/.ssh/id_xmss type -1
debug1: identity file /home/ian/.ssh/id_xmss-cert type -1
debug1: identity file /home/ian/.ssh/id_dsa type -1
debug1: identity file /home/ian/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.3
debug1: Remote protocol version 2.0, remote software version babeld-70f1bac9
debug1: compat_banner: no match: babeld-70f1bac9
debug1: Authenticating to github.com:22 as 'git'
debug1: load_hostkeys: fopen /home/ian/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU
debug1: load_hostkeys: fopen /home/ian/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'github.com' is known and matches the ED25519 host key.
debug1: Found key in /home/ian/.ssh/known_hosts:1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /home/ian/.ssh/id_rsa 
debug1: Will attempt key: /home/ian/.ssh/id_ecdsa 
debug1: Will attempt key: /home/ian/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/ian/.ssh/id_ed25519 ED25519 SHA256:nyKlW1+YfdDV4wAg8UqrA4DTmqd47nWcbjxLVmTWZoE
debug1: Will attempt key: /home/ian/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/ian/.ssh/id_xmss 
debug1: Will attempt key: /home/ian/.ssh/id_dsa 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,ssh-ed25519,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256,rsa-sha2-512,rsa-sha2-256,ssh-rsa>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ian/.ssh/id_rsa
debug1: Trying private key: /home/ian/.ssh/id_ecdsa
debug1: Trying private key: /home/ian/.ssh/id_ecdsa_sk
debug1: Offering public key: /home/ian/.ssh/id_ed25519 ED25519 SHA256:nyKlW1+YfdDV4wAg8UqrA4DTmqd47nWcbjxLVmTWZoE
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/ian/.ssh/id_ed25519_sk
debug1: Trying private key: /home/ian/.ssh/id_xmss
debug1: Trying private key: /home/ian/.ssh/id_dsa
debug1: No more authentication methods to try.
git@github.com: Permission denied (publickey).

I can see all sorts of references to /home/ian, but I am doing all this in /media/GH, so it seems that's what might be going wrong. How do I fix that?

[sweh]

Do you have any keys in ~/.ssh ? If not you can move your key files to that directory; move ssh to ~/.ssh/id_ed25519 and ssh.pub to ~/.ssh/id_ed25519.pub

These are the default places ssh looks for keys. The directory you are in isn't relevant; it's where ssh looks for the keys that's important.

[BeebMaster]

Seems I have something:

Code: Select all

ls ~/.ssh
id_ed25519  id_ed25519.pub  known_hosts  known_hosts.old

Do I just overwrite them with the ones in "GH"?

I think I did this because I wanted to keep everything related to GH on my special "GH" volume (which is a USB stick). Can I not do that?

[sweh]

By default, if you do "ssh remotehost" then it will look in ~/.ssh to find the keys.

With standard ssh you can use "-i" to tell to look elsewhere ("ssh -i /media/GH/ssh remotehost"). I've not tried beating git up to work that way.

If you have ssh-agent running (it might be; my Debian 11 starts it when I log in so your Ubuntu might) then you can do "ssh-add <your-key>" (eg ssh-add /media/GH/ssh) then ssh will also ask the agent for the key, and that'll work.

Or else putting a stanza in ~/.ssh/config similar to

Code: Select all

Host github.com
  IdentityFile /media/GH/ssh

will tell ssh to use that key.

[BeebMaster]

Hmmm I have this in my bash history, about 800 entries ago:

Code: Select all

 1380  git clone git@github.com:beebmaster/ADFS.git
 1381  ssh -T git@github.com
 1382  ssh-add -l -E sha256
 1383  ssh -T git@github.com
 1384  git
 1385  git clone
 1386  ssh-add /media/GH/ssh
 1387  ssh -T git@github.com
 1388  ssh-add -l -E sha256
 1389  git clone git@github.com:beebmaster/ADFS.git
 1390  git add

Just done it again now and it seems to have been accepted:

Code: Select all

ssh-add /media/GH/ssh
Identity added: /media/GH/ssh (beebmaster@beebmaster.co.uk)

And:

Code: Select all

git push origin HEAD
Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 12 threads
Compressing objects: 100% (15/15), done.
Writing objects: 100% (15/15), 1.81 KiB | 1.81 MiB/s, done.
Total 15 (delta 13), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (13/13), completed with 13 local objects.
To github.com:beebmaster/ADFS.git
   c7b25a3..d676ee9  HEAD -> master

Praise be!

The only thing I can think of is that some package update at some point unravelled it all, but at least I know how to fix it now!

Thanks so much!

[sweh]

If you logout/reboot then ssh-agent is killed and you will need to do a new "ssh-add" to add the key back in.

You can see what keys are loaded with "ssh-add -l"

[BeebMaster]

Ah. Well, that will be it then, as I power off every time I go out.

Looks like I will have to add it to the config file then.

[BeebMaster]

I didn't have one, but I made one, and it looks like I've cracked it now:

Code: Select all

2023-09-19 21:53:10 ian@BMDesktop2020:/media/GH/ADFS$ git push origin HEAD
Everything up-to-date
2023-09-19 21:53:18 ian@BMDesktop2020:/media/GH/ADFS$ ssh-add -l
The agent has no identities.
2023-09-19 21:53:27 ian@BMDesktop2020:/media/GH/ADFS$ cat ~/.ssh/config
Host github.com
  IdentityFile /media/GH/ssh
2023-09-19 21:53:31 ian@BMDesktop2020:/media/GH/ADFS$ 

Hopefully I can forget about all this for the next 12 years now, like everyone else.

[mfaxford]

I'm a bit late to this thread, but I'd agree with the earlier comments that git is a worthwhile tool to learn. It's best to learn many of the good practices from the beginning (e.g. always work in a branch not directly in main/master). I came to git from CVS/Subversion so learning the git way has taken some work (and I still sometimes forget to work in a branch).

GitHub doesn't show you the actual key any more, just the SHA256.

It is possible to get the keys out from github but I'm not sure how well documented it is. If you visit https://github.com/<username>.keys you get the keys in the same format as the ~/.ssh/authorized_keys file. I've often used this for setting up user accounts as it's relatively easy to curl/wget a set of public keys for someone.