Hacker News Reader

Comment by nerdjon | Hacker News Reader

So I have never actually tried, but could you not just have multiple SSH keys in your .ssh folder and run the same command in the article telling git specifically which one to use instead of one within the git directory?

That seems like it would fix the issue here without introducing a major security issue.

To be blunt... If I was security at a company and found out someone was doing this, I would question why they have the right to use git frankly.

Edit: I should have clicked through to the superuser article which answered my question that this is perfectly fine with git and having multiple in .ssh.

So honest question... why did you think this was a necessary "twist" worth the risks of copying those files to a location it should not be?

View on HN

You don't even need to do that. You can just put each set of repos in a directory on a per-account basis and set up git-configs for each. The top of my `.gitconfig` looks like

    [includeIf "gitdir:~/Work/"]
      path = .gitconfig_work
    [includeIf "gitdir:~/OpenSource/"]
      path = .gitconfig_opensource

where `Work` is where all of our repos associated with our GitHub EMU go and `OpenSource` is where I clone all of the open source repos I need to contribute to for work. Our EMU policy doesn't allow us to use our EMU accounts on other repos (or maybe this is just a general restriction of EMU) so I have that set-up to use my personal GitHub.

This is exactly what I have set up for a pair of personal accounts. Allows for a nice clean split between the two. As long as the code was initially cloned into the correct directory there's no way for me to accidentally use the wrong email address or GPG signing key.

You can also use your ssh config to set identities for any "host" you want, and the host doesn't need to be the real hostname. So you can do something like:

  Host project1.git
    Hostname github.com
    IdentityFile ~/.ssh/id_project1_ed25519
    IdentitiesOnly yes

And then "git checkout git@project1.git:foo/project1.git" to checkout the file.

I have a ssh-switch script that runs `ssh-add -D` and `ssh-add $KEY_FILE` so I can do `ssh-switch id_github`, etc. This is coupled with a `/etc/profile.d/ssh-agent.sh` script to create a ssh agent for a terminal session.

yes. ssh keys can be named whatever and you can have as many of them in your .ssh dir (or any dir) as you want. "id_ed25519.pub" is just a default/convention.

run "ssh -vvv" and you will see how ssh client decides to look thru that directory. it will try all of them if none are specified.

My question was more the git command in the article I was curious about, I have never used that command myself and I was not sure if there was a weird limitation (possibly related to the git context) that it only worked with files within the git repo.

I am just trying to figure out how we are jumping from storing in ~/.ssh to storing in the repo here.

Yes, you can run in your local git repo:

  git config core.sshCommand "ssh -i /home/your_user/.ssh/your_custom_key"

(I believe replacing "/home/your_user" with "~" works too)

I use this all the time as my main key is ed25519 but some old repositories only support rsa keys.

The sshCommand config is, as the name says, the literal ssh command that is used by git when operations that call a remote with ssh (usually push/pull). You can also put other ssh options in there if you need.

Another option to achieve the same effect is to setup directly in your ~/.ssh/config:

  Host your_custom_alias
    HostName git.domain.com
    User git
    IdentityFile ~/.ssh/your_custom_key

then instead of "git clone git@git.domain.com:repo.git" you clone it with "git clone your_custom_alias:repo.git" (or you change the remote if is already cloned). In this case you don't need to have to change the git sshCommand option.

I guess this is why

> This setup is localized to that repo and is entirely self-contained, i.e. you can move the repo to a different path or place it on a thumb drive to a different machine and it will work without reconfiguring.

I mean I saw that, but I just can't imagine this is thing that you are honestly doing that much...

But also:

> you can move the repo to a different path

Pretty sure this alone is a non issue.

> place it on a thumb drive to a different machine and it will work without reconfiguring.

I go back to this being terrible security. If you loose that drive someone now has your key and the ability to figure out where that key is valid for.

> the ability to figure out where that key is valid for

Not just the ability to figure it out, but the config is set to use it automatically, so you could easily figure this out on accident.

Reply on news.ycombinator.com