I am getting a strange issue where ssh with keys (password is ok) on MacOS Tahoe 26.5 (m4) does not send the key. Did anyone else encounter this by any chance? I think the permissions for the keyfiles are fine , the last thing that

ssh -vvv

gives me is:

debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug3: ssh_get_authentication_socket_path: path '/var/run/com.apple.launchd.hUfVPmkSdT/Listeners'

and then does nothing forever

what kind of key are you using?

its an rsa key

Thats your issue

😞

Add this to the config

PubkeyAcceptedKeyTypes +ssh-rsa

I will give it a shot

MacOS openssh hasn’t accepted rsa keys for a couple of versions now

Also make sure you are you telling it which key to use. On the command line, it's the

-i

option, in

.ssh/config

(not sure if that's the same on a Mac) it is

IdentityFile

. If you don't and you gave your key a name that differs from the handful standard names it looks for, it will ignore it.

Both are still available on the MacOS version 🤷🏻

In the link I posted an important point is that there can be multiple algorithms for one key type. Make sure you allow all the relevant ones.

ssh -Q PubkeyAcceptedAlgorithms

gives you the full list of acceptable values. BTW, while

ssh-rsa

is in that list, it is not in the default list for my system, but several algorithms with

rsa

in the name are. Not sure if

ssh-rsa

is an umbrella term for all (or at least several) RSA algorithms.

Thanks a lot. I have tried to add either

PubkeyAcceptedKeyTypes +ssh-rsa

or

PubkeyAcceptedAlgorithms +ssh-rsa

to my config, but the result remains the same. It is also a bit strange, because on my old mbp (which is also on tahoe) it works fine and I am basically using the same

.ssh

folder

You could try allowing some other algorithms from

ssh -Q PubkeyAcceptedAlgorithms

, but the way this looks like to me is that the only real difference is the hardware (and likely the drivers for it), so my hypothesis is that the new hardware changes the result of the decryption with your key, leading to an authentication failure -- seems far-fetched, but consistent with your observations ... Can you generate a new key with a different algorithm (ed25519 seems to be recommended) and use that on the server?

It looks like you have some form of agent, do you have

SSH_AUTH_SOCK

set? If so, does unsetting/pointing to

/dev/null

help? Does

ssh-add -L

work and list your key?

The agent would help with password-protected keys. If that doesn't work for some reason (problem with the agent, key not added to the agent, etc.), it should fall back on asking for the password to use the key, rather than refusing to (or being unable to) use the key.

Since the supposed issue here is the client hanging, it could at least be the client waiting for the agent to provide services. While I think it should time out eventually, that in itself allows the client to e.g. ask the user for confirmation that the key can be used, so we're likely talking about minutes in timeout rather than seconds - assuming the agent is functional at all.

Yeah, I don't know anything about Macs, in my (Linux) experience

ssh

checks if there is an agent that has the correct password, and if not, it immediately prompts the user for one. My inclination would be to try to get it to work without agent, and once that works, make it work with the agent.

Thanks a lot @pontus, unsetting SSH_AUTH_SOCK fixed the problem!

Not sure what you mean, but I'd definitely expect some other failure mode if the issue what that you couldn't connect to the socket.

I am not sure, but restarting ssh-agent created a socket in a different directory and now it seems ok

I don't know if macOS connects to Keychain automatically, but I wouldn't be surprised. If so, it may be that it defaults to wanting approval for each use unless you configure it differently.

I admit that I also know nothing about what ssh on macOS does and how it intergrates with the system

Similarly I suspect

eval $(ssh-agent -s)

will set you up with a completely different agent than you normally have...

ssh was one of those things that seemed to just work fine so I was happy it did its job.. I think it is still a bit broken, because even though I can now connect with keys again,

ssh-add -L

returns

Could not open a connection to your authentication agent.

That would be excepted if you unset

SSH_AUTH_SOCK

since it no longer knows where to talk to the agent.

Hm, i see, restarting the agent fixes that. What exactly is the job of the agent, managing keys? Why does it help me connect if I disable it, is it because I happen to have the identityfile by path and not just name in my ssh config?

The ssh client has enough smarts to use keys by itself (at least normal ones), but having it use the keys directly will require unlocking (with passphrase typing) on each use.

Ah, I understand, thanks for the clarification

Glad you got it sorted out! The

ssh-agent

uses two environment variables so it can be contacted,

SSH_AGENT_PID

(the process ID), and

SSH_AUTH_SOCK

(the socket it uses for communication). These get normally set when the agent get started (

ssh-agent -s

prints the statements setting these variables, and if you wrap that in

eval $(...)

, those statements get executed and the variables set). When the agent dies for whatever reason, the variables remain and make it look like there is still an agent running, which will lead to errors, because the values of these variables are not applicable anymore. Restarting the agent fixes that.

(But such a dead agent would result in lack of agent functionality, not the kind of hang reported :)

That's what I would expect, but apparently the agent was not dead, but had weird permissions (and maybe ownership?). I have no idea how that would happen and have never experienced the effects. (My explanation was meant to be more general, focused on why the environment variables are needed.)

I suspect this is a macOS thing where the Keyring is used as agent by default but possibly has some UX quirk.

Yeah, not sure what is going on, when it hangs the ssh_auth_sock is

/var/run/com.apple.launchd.hUfVPmkSdT/Listeners

, now that it works it is at

/Users/<User>/.ssh./agent/<random>

Could it be that you have more than one agent running at the same time, e.g. one started by the "system" for its purposes (my Linux system does that) and one started explicitly by user processes (e.g. your login scripts) for SSH? (On my system I am co-opting the "system's" agent [which runs under my name] also my SSH purposes, but that was a conscious decision and by no means the only way to do this.) If that's the case, and they run as different users, or something, it might explain what you experienced.

I guess thats one option out of several options of what could be going wrong. I dont really know what introduced the problem since i did an OS update + device switch, assuming that things will magically work. If it happens again I will take another look

Issues due to multiple agents seem unlikely, it's not at all an uncommon scenario (and the interface to an agent is just a UNIX socket, that we have plenty of).