Agent doesn't work with Git inside a Node.js script using a SSH + SSO key on GitHub

Eramdam
Eramdam
Community Member

I've been trying to switch to using the 1P SSH Agent full-time and while it's working great for my regular servers' SSH and commit signing, the SSH Git(Hub) connections are giving me issues when git is ran from/by a Node.js script when using a key in a repo that uses SAML single sign-on

The problem

Considering the following SSH config:

Host *
  IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

Host github.com
  IdentityFile ~/.ssh/keys/github.pub

Where github.pub is the public key of an SSH key from my vault.

Using the git CLI in a regular context (fish shell 3.5.1 in iTerm2 3.5.0beta9) works fine and prompts the Agent like expected:

However, running inside the same repo but using the git command inside a script causes an error. Considering the following script:

import { exec } from "child_process";

(async () => {
  exec(
    'GIT_SSH_COMMAND="ssh -v" git pull',
    { cwd: process.cwd() },
    console.log
  );
})();

yields the following error when ran

debug1: SSH2_MSG_EXT_INFO received
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/damien/.ssh/keys/github.pub ED25519 SHA256:4qAKLnbwSPfhZggpEDaJRo5SQe982Do8A6vOS6jAcEM explicit agent
debug1: Server accepts key: /Users/damien/.ssh/keys/github.pub ED25519 SHA256:4qAKLnbwSPfhZggpEDaJRo5SQe982Do8A6vOS6jAcEM explicit agent
sign_and_send_pubkey: signing failed for ED25519 "/Users/damien/.ssh/keys/github.pub" from agent: agent refused operation
debug1: No more authentication methods to try.
git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

With those interesting warnings in 1Password's log file when the script runs

WARN  2023-01-06T20:16:59.064 tokio-runtime-worker(ThreadId(6)) [1P:ssh/op-session-info/src/macos.rs:37] no top level process found, launchd is missing from process tree
WARN  2023-01-06T20:16:59.064 tokio-runtime-worker(ThreadId(6)) [1P:ssh/op-ssh-agent/src/lib.rs:426] Unable to get client_info for pid: 1077

My current (hacky) workaround

After battling for two days with my SSH config file I figured out a workaround. It's not pretty but it works fine:

  • Remove the Git bit from my main ssh config
  • Create another config file in .ssh, named config-git
  • Put the Git bit from before in that newly created file
  • Set the GIT_SSH_COMMAND value to ssh -F ~/.ssh/config-git
  • Export the private key of my Git SSH key
  • Run ssh-add --apple-use-keychain <path_to_key_file>
  • Now both a regular git pull and the script above works.

1Password Version: 1Password for Mac 8.9.12 (80912004)
Extension Version: Not Provided
OS Version: macOS 13.1
Browser:_ Not Provided

Comments

  • Eramdam
    Eramdam
    Community Member

    It seems i can't edit my message but, after testing some more, the default configuration (one single file and the 1P agent globally) sometimes work and sometimes doesn't. It might work on one run of the script above but then won't on another one. It's all very weird.

  • Eramdam
    Eramdam
    Community Member
    edited January 2023

    The script in my OP is a minimal reproduction. The full script is a deploy script we use at work, so I can't really share it.

    And AFAICT the difference in the env content doesn't seem really useful

    https://gist.github.com/eramdam/1e5cb8e3345ac16f96ccb2f16ae013f9

  • Eramdam
    Eramdam
    Community Member

    Now that I post and updated to the newest Nightly build (81000010), I feel like it's all working as expected with the default config. I'll report back to see if the issue comes back πŸ˜…

  • Hey @Eramdam, thanks for the updates, and apologies for not getting back to you sooner. I'm happy that it seems like things are working for you now, but if you run into troubles feel free to report back and we'll take a look.

  • Eramdam
    Eramdam
    Community Member
    edited January 2023

    Okay so: regular git operations within the affected repos work fine with the default configuration but running git inside the provided simple Node script still fails randomly.

    The deploy script we use at work basically does this

    import {exec} from 'child_process';
    
    (async () => {
      exec('git rev-parse ....', {cwd: process.cwd()}, () => {
        exec('git fetch ...', {cwd: process.cwd()}, () => {
          exec('git log ...', {cwd: process.cwd()}, () => {
            exec('git push origin foo:bar', {cwd: process.cwd()}, console.log);
          });
        });
      });
    })();
    

    So I'll run into situations where the git fetch succeeds but not the final git push, or vice versa or sometimes everything will work or sometimes nothing will. I'm starting to think that when it works it's "by accident" because I can't figure out a clear pattern 😞

    This is all while running 1Password for Mac 8.10.0 (81000012)

  • HI @sitepodmatt, I'm sorry to learn that the SSH agent hasn't met your needs. There are some improvements coming which we hope will improve your experience substantially. Stay tuned for updates ahead - we'll be happy to have your feedback.

  • Eramdam
    Eramdam
    Community Member

    I switched back to using my original workaround for now. It requires adding my private GitHub key to my OSX ssh-agent but it works πŸ˜…

  • Hi @Eramdam:

    Thanks for following up, and I'm sorry that you had to revert to the regular SSH agent here. As Peter mentioned, we're actively working on improvements here.

    Jack

  • Eramdam
    Eramdam
    Community Member

    I'm now running 1Password for Mac 8.10.1 (81001019) and I guess whatever agent changes you were thinking about landed recently because it seems like my described use-case now works without my hacky workaround πŸŽ‰

    I'll test it during this work week to confirm but so far so good πŸ˜„

  • Jack.P_1P
    edited March 2023

    Hey @Eramdam:

    Glad to hear it! Let us know how it goes. πŸ™‚

    Jack

This discussion has been closed.