Actually, turns out that the quoting abilities of SSH are rather limited and you cannot embed or escape quotes within quotes, meaning I cannot do something like Match host * exec "test -z \"$SSH_CONNECTION\"" or Match host * exec 'test -z "$SSH_CONNECTION"'.

I did find out another way of checking string length in POSIX shell, though, so I could do this instead:


Match host * exec "test ${#SSH_CONNECTION} == 0"
IdentityAgent "~/.1password/agent.sock"


Haha, weird, the site was indeed served in from the mobile endpoint (which is using a different markup, not just a responsive layout) and had a different look, but I never noticed the first two characters missing in the codeblock as the indented bits looked fine. The mobile version looked fine when I opened DevTools and checked off a mobile browser before reloading, so it seemed to only apply to the actual device. Maybe just a fluke, who knows :)

Anyway, this worked (almost flawlessly, see below), so thanks for that!

ssh -v git@github.com
...
Hi fatso83! You've successfully authenticated, but GitHub does not provide shell access.


But ... there was something wrong in the shell command, as you might spot from the verbose output, see line 4:

$ LC_ALL=C ssh -v git@github.com
OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /home/carlerik/.ssh/config
debug1: Executing command: 'test -z $SSH_CONNECTION'
/bin/bash: line 1: test: too many arguments
...


After some debugging, I found it was simply missing quotes, as the $SSH_CONNECTION variable would result in multiple tokens:

```
$ LC_ALL=C eval 'test -z $SSH_CONNECTION'
-bash: test: too many arguments

$ eval 'echo test -z $SSH_CONNECTION'
test -z 127.0.0.1 55738 127.0.0.1 22

Adding quotes:

$ eval 'test -z "$SSH_CONNECTION"'

$ # no error :)
```

Adding quotes would remove the error, but it really made no functional difference: we were only supposed to use the on-host 1Password agent if the test command failed, and it only failed (for the wrong reasons) if the string we tested for was present :)

I'm guessing something didn't render correctly. Here's the same code block as a screenshot:

So there's no tch keyword, it's Match.

Clever! Didn't cross my mind. May I ask what the tch in the tch line is? I tried googling "ssh_config tch", but came up short and I cannot access man pages on my mobile 🙈

I understand what the line is doing, but tried fruitlessly to decrypt the name. "Try conditional host"?

What you could do is in your SSH config, enable SSH agent forwarding for the host you're connecting to:


Host myhost
ForwardAgent yes


Then on your target machine, only apply the 1Password socket without an existing SSH connection:

Match host * exec "test -z $SSH_CONNECTION"
IdentityAgent "~/.1password/agent.sock"


If there is an SSH connection, it should pick the forwarded SSH_AUTH_SOCK. If you'd then run an SSH command, you'd get prompted on the original machine.

Yes, I do, but as previous discussions have shown I https://1password.community/discussion/136955/exotic-possible-to-make-1password-browser-extension-connect-to-1password-over-ssh-or-other-means, so I am not sure how that plays in?

Here is the typical usecase:
I am at home and remember I forgot to push some code to Github when I was at work. So I
1. ssh into my work computer
2. find the folder and do git push
3. Realise the git push command never exits, as 1Password has now started a prompt in the GUI (which I cannot see in the terminal)
4. Give up (or configure ssh to use a key not provided by 1Password, which is less ideal)

After unlocking 1Password the first time it is integrated with the operating system lock, so the prompt to unlock is probably the operating system unlock prompt. Or it is the dialogue that asks to permit the terminal to use the Github SSH key, if I hadn't done that previously in the same session.

Do you also have 1Password installed on the machine you're connecting from?