¿Por qué usar la versión ".local" de un nombre de máquina "soluciona" el problema de SSH que parece haber sido causado por Sequoia?

El problema no tiene nada que ver con SSH. Prueba ping sellotape y ping sellotape.local y verás algo diferente, como señaló Linc "nunca debería haber sido así".

Los dominios .local funcionan, ya que siguen el protocolo mDNS. En los dispositivos de Apple esto es manejado por Bonjour's mDNSResponder, en dispositivos Linux (como tu Raspberry Pi) típicamente es manejado por avahi-daemon.

¿Has escrito algo en tu /etc/hosts? Si lo hiciste (y probablemente lo hiciste), y tienes entradas DHCP estáticas en tu router, entonces desactivar la dirección Wi-Fi privada lo soluciona porque "aleatoriza" tu dirección MAC y así tu router no reconocerá este dispositivo. Pero realmente no deberías configurar manualmente entradas DHCP e direcciones IP, a menos que tengas una razón justificada para hacerlo. mDNS es (casi) siempre el camino correcto a seguir.

Ahora, después de quitar las entradas de /etc/hosts y las configuraciones DHCP estáticas, puedes lograr el mismo efecto (ssh sellotape sin el sufijo .local) agregando las siguientes líneas a tu archivo ~/.ssh/config:

Host sellotape
    HostName sellotape.local

Si sellotape.local resuelve, esto siempre funcionará.

Este comportamiento es normal. "Sellotape" y similares no son nombres de dominio completamente calificados. Solías poder ingresar .local en la configuración de red como un dominio de búsqueda, y el nombre completo se inferiría, pero eso ya no funciona para SSH, como de hecho nunca debería haberlo hecho, porque la ambigüedad es un agujero de seguridad potencial. Simplemente acostúmbrate a ingresar todo el nombre de multidifusión.

Bueno, creo que finalmente entendí esto. Si activas la dirección Wi-Fi privada entonces la Mac ignora la configuración de reserva de dirección del enrutador y elige una dirección Wi-Fi, aparentemente al azar.

Mi enrutador está configurado para asignar a "Sellotape" la dirección IP 192.168.0.76. Con la dirección Wi-Fi privada habilitada, la Mac eligió 192.168.0.70 que, por supuesto, es diferente de la IP en el archivo de hosts. Con la dirección Wi-Fi privada deshabilitada, funciona:

Fifteen:~ mnewman$ ssh sellotape
Último inicio de sesión: Jue Oct  3 04:56:58 2024 desde 192.168.0.78
Sellotape:~ mnewman$

Puede que tenga un problema si está utilizando extensiones de red de terceros como LuLu / Little Snitch / VPNs / Crowdstrike ;-) Al parecer, Sequoia ha introducido un error en la versión 15.0 donde el firewall de macOS no funciona bien con otros productos. Supuestamente, Apple lo ha reconocido y solucionado en la versión 15.1 Beta, pero no tengo referencia de eso.

• https://techcrunch.com/2024/09/19/apples-new-macos-sequoia-update-is-breaking-some-cybersecurity-tools/

Personalmente tuve un problema con conexiones ssh interrumpidas a mi NAS RPi4 local, generalmente con algún tipo de error de encriptación, y copias de archivos interrumpidas sobre SMB desde el mismo dispositivo.

Me preguntaba si había una mala interacción con LuLu, y terminé desinstalando LuLu (parece que deshabilitar no es suficiente) hasta que Apple resuelva el problema.

• https://github.com/objective-see/LuLu/issues/639

La opción parece ser deshabilitar cualquiera de las extensiones de terceros o el FW de macOS.

Problemas de SSH:

• https://forums.macrumors.com/threads/macos-sequoia-builtin-firewall-does-not-allow-ssh-login.2436706/

Problemas de DNS (que pueden estar relacionados con su problema - si ambas máquinas están en el mismo dominio, .local sería innecesario como usted sabe):

• https://mjtsai.com/blog/2024/09/18/macos-firewall-regressions-in-sequoia/

Otro problema que tiene el firewall de macOS es que no se pueden editar las reglas existentes. El botón - en el diálogo está inactivo. Presumiblemente se puede hacer en Terminal pero no he experimentado.

• https://discussions.apple.com/thread/255759412?sortBy=rank