Ssh on ¬ just serendipity 🍀

★ New script: SSH mux restart

serendipity@perrotta.dev (Thiago Perrotta) — Thu, 30 Oct 2025 12:59:53 +0100

After experiencing almost daily frustration because of this SSH auth issue, I decided to script a solution out of it: and now ssh_mux_restart was born.

A copy of the README.md follows below for ease of reference.

The use case is very simple: run the ssh_mux_restart script whenever I run into a git SSH authentication error, typically due to git pull, git fetch or git push.

Usage #

Basic usage to kill SSH multiplexed connections:

./ssh_mux_restart.sh

To also restart the 1Password SSH agent:

./ssh_mux_restart.sh --restart-1password

Example Output #

% ./ssh_mux_restart.sh
Finding SSH multiplexed connections...
Found SSH multiplexed connections:
  88002 ssh: /tmp/ssh-control-FLAPJACK42 [mux]
  88123 ssh: /tmp/ssh-control-WAFFLE55 [mux]
Killing SSH multiplexed connections...
✓ Killed SSH mux process: 88002
✓ Killed SSH mux process: 88123
Killed 2/2 SSH multiplexed connections.

All operations completed successfully!

With the --restart-1password flag:

% ./ssh_mux_restart.sh --restart-1password
Finding SSH multiplexed connections...
Found SSH multiplexed connections:
  88002 ssh: /tmp/ssh-control-PANCAKE99 [mux]
Killing SSH multiplexed connections...
✓ Killed SSH mux process: 88002
Killed 1/1 SSH multiplexed connections.

Restarting 1Password application...
Found 1Password process: 67690
Quitting 1Password...
✓ 1Password quit successfully
Starting 1Password...
✓ 1Password started successfully
1Password SSH agent is now ready for use.

All operations completed successfully!

Why This Matters #

SSH multiplexed connections can cache stale authentication credentials, causing issues when:

GitHub organizations enable or enforce SAML SSO
1Password SSH agent credentials need refreshing
SSH keys have been rotated or updated

Restarting these connections forces SSH to re-authenticate with fresh credentials.

Prerequisites #

Standard Unix tools (pgrep, pkill)
1Password app (macOS) if using the --restart-1password flag

— § —

Reply via email

#bestof #dev #ssh

GitHub: the organization has enabled or enforced SAML sso

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 21 Oct 2025 08:15:41 +0200

♠ Error message when doing git push:

% git push
ERROR: The '{corp}' organization has enabled or enforced SAML SSO.
To access this repository, you must use the HTTPS remote with a personal access token or SSH with an SSH key and passphrase that has been authorized for this organization.
Visit https://docs.github.com/articles/authenticating-to-a-github-organization-with-saml-single-sign-on/ for more information.

fatal: Could not read from remote repository.

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

Even after authenticating by logging in, the error persists.

The solution is to restart the ssh agent.

How to do so is out of scope of this post, because it depends on which one you use.

For the 1Password ssh agent, the following has worked for me:

disable it by toggling the checkbox: Settings > Developer > SSH Agent > Use the SSH Agent
kill the ssh agent (pkill ssh-agent)
kill open ssh multiplexing connections (e.g. with pkill):

% pgrep -afl ssh
48564 ssh: /tmp/ssh-control-bda8786786c69753cc9ddd9fb7c06aaff3768a70 [mux]
50845 ssh: /tmp/ssh-control-bda8786786c69753cc9ddd9fb7c06aaff3768a70 [mux]

quit 1Password, then reopen it
re-enable the 1Password ssh agent
git push again

Surely there is a way to script this?

Update(2025-10-28): In a second try, killing the process below was enough to address the issue.

% pgrep -afl ssh
7242 ssh: /tmp/ssh-control-bda8786786c69753cc9ddd9fb7c06aaff3768a70 [mux]
% kill 7242

— § —

Reply via email

#dev #security #ssh

SSH: hash known hosts

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 15 Jun 2025 12:05:11 +0200

♠ A security / privacy tip: hash ssh hosts, especially in machines you have access to that are in the cloud. ~/.ssh/config:

Host *
	# Automatically hash new host keys added to ~/.ssh/known_hosts.
	# Manually for pre-existing hosts: ssh-keygen -H
	HashKnownHosts yes

The default is not to hash.

As a side effect, ~/.ssh/known_hosts (sample entry):

|1|F1E1KeoE/eEWhi10WpGv4OdiO6Y=|3988QV0VE8wmZL7suNrYQLITLCg= sh-ed25519 [...]

Why do this? As per Security Stack Exchange:

The only change is that if a machine is compromised, the idea is to minimize how much usable information is given to an attacker.

To retroactively hash existing entries, run:

% ssh-keygen -H
/Users/tperrotta/.ssh/known_hosts updated.
Original contents retained as /Users/tperrotta/.ssh/known_hosts.old

— § —

Reply via email

#dev #privacy #security #ssh

git pull: authentication issues

serendipity@perrotta.dev (Thiago Perrotta) — Tue, 03 Jun 2025 14:35:04 +0200

♠ git pull authentication issues is really a disguise for ssh auth issues.

Today a teammate could not git pull one of our internal repos:

% git pull
Enter passphrase for key '/Users/user/.ssh/id_ed25519':
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.

The first thing we verified was that his public key was added to his github profile, and that the private key was present in ~/.ssh/id_ed25519.

Next, verify ~/.ssh/config:

Host github.com
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519

Looks fine. Then:

% export GIT_SSH_COMMAND="ssh -vvv"
% git pull
[...]
debug3: Search for item with query: {
    acct = "/Users/user/.ssh/id_ed25519";
    agrp = "com.apple.ssh.passphrases";
    class = genp;
    labl = "SSH: /Users/user/.ssh/id_ed25519";
    nleg = 1;
    "r_Data" = 1;
    svce = OpenSSH;
    "u_AuthUI" = "u_AuthUIF";
}
debug2: Unexpected keychain error while searching for an item: User interaction is not allowed.

Herein lies the error! The interaction with the system keychain in macOS was not successful.

I suggested him to remove AddKeysToAgent and UseKeychain from this config file, but that did not work either:

% git pull
[...]
Enter passphrase for key '/Users/user/.ssh/id_ed25519':
debug2: no passphrase given, try next key
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
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.

The ssh key is protected with a passphrase.

In this case, it’s better to fix the keychain issue. We readd the two deleted lines.

Restart the ssh-agent and readd the key there:

% eval "$(ssh-agent -s)"
% ssh-add -K ~/.ssh/id_ed25519

Problem resolved! git pull works now.

— § —

Reply via email

#dev #git #security #ssh

1Password SSH agent error

serendipity@perrotta.dev (Thiago Perrotta) — Wed, 07 May 2025 12:52:00 +0200

♠ A day in the life:

% ssh {my-server}
STDERR:
    sign_and_send_pubkey: signing failed for ED25519 "/Users/thiago/.ssh/id_ed25519" from agent: agent refused operation

    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.

What’s the matter?

My ssh config is integrated with the 1Password ssh agent:

Host *
        # Use 1Password SSH agent when available
        # macOS only
        # Linux: "~/.1password/agent.sock"
        IdentityAgent "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock"

Solution: Ensure 1Password is unlocked, so that the agent can be used.

It can be unlocked from its macOS app, or from the CLI (op signin --account {my-account}).

— § —

Reply via email

#dev #macos #security #ssh

Be aware that your public SSH keys can reveal your identity

serendipity@perrotta.dev (Thiago Perrotta) — Fri, 03 May 2024 16:46:28 +0200

♠ If you have a GitHub account configured with SSH, your public keys are available at https://github.com/$USERNAME.keys.

For example, mine: https://github.com/thiagowfx.keys

And then let’s say you also use your full name on GitHub.

% ssh whoami.filippo.io
The authenticity of host 'whoami.filippo.io (2a09:8280:1::a:5d6)' can't be established.
ED25519 key fingerprint is SHA256:qGAqPqtlvFBCt4LfMME3IgJqZWlcrlBMxNmGjhLVYzY.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'whoami.filippo.io' (ED25519) to the list of known hosts.

    +---------------------------------------------------------------------+
    |                                                                     |
    |             _o/ Hello Thiago Perrotta!
    |                                                                     |
    |                                                                     |
    |  Did you know that ssh sends all your public keys to any server     |
    |  it tries to authenticate to?                                       |
    |                                                                     |
    |  We matched them to the keys of your GitHub account,                |
    |  @thiagowfx, which are available via the GraphQL API
    |  and at https://github.com/thiagowfx.keys
    |                                                                     |
    |  -- Filippo (https://filippo.io)                                    |
    |                                                                     |
    |                                                                     |
    |  P.S. The source of this server is at                               |
    |  https://github.com/FiloSottile/whoami.filippo.io                   |
    |                                                                     |
    +---------------------------------------------------------------------+

Shared connection to whoami.filippo.io closed.

Then be careful when connecting to random public ssh servers when you have an intent to be anonymous.

It’s possible to “hide” yourself by either setting the IdentitiesOnly=yes option, or by removing all your local ssh keys altogether, even if only temporarily.

— § —

Reply via email

#dev #privacy #security #ssh

★ SSH plus tmux automatically

serendipity@perrotta.dev (Thiago Perrotta) — Sun, 13 Feb 2022 20:20:27 -0500

♠ One of the most classic sysadmin/DevOps tasks is to use secure shell to connect to remote machines.

To persist those connections, a terminal multiplexer is often used, tmux and screen being the two most popular ones.

In this post I will cover a few different client-side and server-side ways to have ssh automatically spawn tmux upon connection.

Option #1: Use command-line ssh flags (client-side, recommended) #

Start tmux, forcing unicode, attaching to and/or creating a session named main:

$ ssh user@host -t -- tmux -u new -A -s main

-u is not strictly necessary, however I experienced occasional weirdness when connecting to some machines and omitting it. Some unicode characters wouldn’t be properly rendered, like the horizontal and vertical lines used to render tmux pane splits. Even though most machines should work just fine these days by supporting UTF-8 out-of-the-box, it’s safer to always include -u just in case.

Tip: If it’s annoying to remember to type the full command above, consider adding an alias in your shell config. Alternatively, use a ssh client that remembers your flags preferences such as the chrome secure shell extension.

Option #2: Use `~/.ssh/config` (client-side) #

This option is very similar to the previous one, but the flags live in the ssh config rather then being specified at the command line:

Host *
  RequestTTY yes
  RemoteCommand tmux -u new -A -s main

You don’t need to match all hosts (Host *), if you’d rather match one or more specific hosts, refer to the ssh config syntax ssh_config(5) to add them. A simple example would be Host mymachine.example.org.

Caveat: I’ve found this method interferes with git + ssh authentication. More specifically:

$ git remote -v
origin	git@github.com:thiagowfx/.dotfiles.git (fetch)
origin	git@github.com:thiagowfx/.dotfiles.git (push)
$ git push
Cannot execute command-line and remote command.
fatal: Could not read from remote repository.

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

Therefore I discourage it, unless you only use it with specific hosts i.e. don’t use it with Host *.

Option #3: Use `~/.bash_profile` or similar (server-side, recommended) #

This method leverages your login shell startup config file (~/.bash_profile, ~/.zprofile, etc) to automatically spawn tmux.

# This file is invoked as part of my ~/.bash_profile.
# Automatically spawn tmux within ssh sessions for interactive terminals.
# https://stackoverflow.com/a/43819740/1745064
#
# The session is called `main`.
# Create a session with PREFIX :new, rename with PREFIX $, toggle with PREFIX s.
#
# Escape hatch:
#   ssh <host> -t -- NOTMUX=1 <shell>
if [ -z "$NOTMUX" ] && [ -z "$TMUX" ] && [ -n "$SSH_TTY" ] && [[ $- =~ i ]]; then
  tmux -u new -A -s main
  exit
fi

The if basically checks:

whether we’re not already inside a tmux session (we shouldn’t be), so that we don’t nest tmux
whether we’re accessing the shell via ssh (we should be)
whether we’re accessing an interactive shell (we should be), so that it doesn’t interfere with oneshot ssh commands

There’s also a escape hatch. If you want to get an interactive shell but bypass tmux for some reason¹, just set NOTMUX=1:

$ ssh user@host -t -- NOTMUX=1 bash

Final remarks #

My favorite methods are #1 and #3, and whether I use one or the other depends whether I want to unconditionally spawn tmux server-side, or selectively spawn tmux client-side.

When using chrome secure shell (hterm) I find #1 convenient because hterm remembers your ssh host settings. That said, in scenarios where I fully control a host and it’s not solely used for production, #3 is my favorite as it works unconditionally regardless of the client terminal emulator I am using.

For example, maybe if tmux broke due to a recent upgrade, or if the ~/.tmux.conf is invalid. ↩︎

— § —

Reply via email

#bestof #dev #security #ssh

Ssh on ¬ just serendipity 🍀

★ New script: SSH mux restart

Usage #

Example Output #

Why This Matters #

Prerequisites #

GitHub: the organization has enabled or enforced SAML sso

SSH: hash known hosts

git pull: authentication issues

1Password SSH agent error

Be aware that your public SSH keys can reveal your identity

★ SSH plus tmux automatically

Option #1: Use command-line ssh flags (client-side, recommended) #

Option #2: Use ~/.ssh/config (client-side) #

Option #3: Use ~/.bash_profile or similar (server-side, recommended) #

Final remarks #

Option #2: Use `~/.ssh/config` (client-side) #

Option #3: Use `~/.bash_profile` or similar (server-side, recommended) #