[vindex10]

I find one disadvantage of SSH key auth, in case of GitHub in particular, that SSH key grants access to all the repos independently on the organization, etc, which becomes a bigger problem when sharing the machine with other people.

One can set a password on the ssh key, but I still felt a bit paranoid about it. I found a way out with fine-grained personal access tokens which allow you to choose the repositories this token will have access to [1].

My setup consists of two ingredients:

1. GPG encrypted fine-grained PAT: `gpg -c --no-symkey-cache --pinentry-mode loopback my_name` ends up into `my_name.gpg` secret.

2. A git credential configuration which is generic across git repositories:

  [credential "https://[e-mail]"]
      helper = "!f() { test \"$1\" = get && echo \"password=$(gpg -d --pinentry-mode loopback --no-symkey-cache $_GITHUB_TOKEN)\"; }; f"

Now switching identities results into setting the env var `$_GITHUB_TOKEN` to the path to my gpg encrypted token, which will be decrypted by git on the fly. You can figure out a suitable way to alias this for yourself :)

And it only activates for git urls of the from "[e-mail]" which allows you to clone public repos without questions.

Another advantage is that you can share the same repo with other people, no need to maintain a copy.

Disadvantage is that you have to enter password each time you push/pull.

[1] https://github.blog/2022-10-18-introducing-fine-grained-pers...

[atoav]

> Disadvantage is that you have to enter password each time you push/pull.

Run ssh-add in your terminal session before doing your push/pull dance — this way you only have to enter the password once. This gives you the security of the password protected key without bothering you too much in practise.

If you need to pull on a remote that doesn't have your private keys (as is good and proper) you can run ssh -A [e-mail] to take that identity with you onto that remote (e.g. so you are able to pus/pull from there).

[vindex10]

thanks for the suggestion. I haven't used agent forwarding myself. I read a bit in the manual, and this seems to have a problem if the users I'm sharing the machine with have `sudo`:

> Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. A safer alternative may be to use a jump host (see -J).

> Run ssh-add in your terminal session before doing your push/pull dance

originally my comment was about gpg encrypted files. also I suspect any kind of agent would expose privileges of my key to others if they have sudo.

[atoav]

Exactly. This should be used with care on remote hosts that are untrusted.

But for local development it is still superior to not having a password at all.

[vindex10]

for local development, I use keychain [1] on top of the ssh-agent.

this allows to keep ssh-agent On for a limited time, so it will ask for password again in, for example, 10 minutes.

[1] https://www.funtoo.org/Funtoo:Keychain

[tjoff]

> I find one disadvantage of SSH key auth, in case of GitHub in particular, that SSH key grants access to all the repos independently on the organization, etc.

Doesn't the article fix exactly that?

[vindex10]

my concern is not the configuration of gitconfig, but keeping the "escalated" ssh keys on the shared machine

if I understood correctly, the article suggests the way how to choose ssh key among those already stored on the server

[organsnyder]

For a shared machine, I'd prefer to have an encrypted home directory (assuming you have separate users).

[vindex10]

yeah, this depends on the use case.

I'm speaking about a situation when the space is shared. Basically every co-worker can ssh into machine and then do `sudo su` into a shared user, under which some R&D script is running and being fixed/adapted once for a while.

For scientific projects it may also be convenient, having a jupyter notebook running under tmux of the same account. Then collaborative (but not concurrent) work is possible on the project.