Preguntando esto aquí porque no creo que sea un problema de Linux.
Mi Mac Mini se encuentra en un escritorio y es la "autoridad central" para todas mis copias de seguridad. Tengo nueve máquinas virtuales de Linux en un servidor en el que se ejecutan los scripts todas las noches, por ejemplo, volcados de MySQL y para bloquear directorios de archivos adjuntos en mis servidores Atlassian. Las copias de seguridad resultantes se copian de forma segura en Mac durante la noche y, por supuesto, forman parte de la copia de seguridad de 'TimeMachine' y, tres veces por semana, cambio una unidad externa a la que se copian los deltas más recientes y tomo Eso en mi oficina para sentarme en mi cajón.
Es un poco una solución 'torpe' que ha crecido a lo largo de los años a medida que mi conocimiento ha aumentado.
Hace dos días, instalé una nueva máquina virtual para ejecutar zabbix y está funcionando bien. Esto significó, por supuesto, la instalación del agente de zabbix en todas las máquinas con Linux, y lo hice todo y también lo ejecuté en la Mac.
Esta mañana, recibí un correo electrónico del servidor de Atlassian, que me decía que no podía rastrear las copias de seguridad, ya que la clave del host había cambiado, y me advirtió que podría haber un "hombre en el ataque central" . No hubo, por supuesto, ya que solo uno de mis servidores está orientado al público, y eso se encuentra detrás de un firewall, tiene firewalld ejecutándose en él y envía todo el tráfico a la red a través de un pequeño servidor RHEL independiente en el que se está ejecutando firewalld. Pero sigo los consejos del correo electrónico, y voy al archivo /home/darren/.ssh/known_hosts y elimino la línea "ofensiva". Solo para asegurarme, verifico el script de copia de seguridad, verifico que está usando los archivos de clave correctos (es - $ HOME / .ssh / id_rsa), y ejecuto un SHS simple en la Mac. Boom - conectado al instante.
Ejecuto el script de copia de seguridad manualmente en el servidor de Atlassian, y en lugar de transferir el archivo a la Mac, obtengo ...
Permission denied (publickey).
lost connection
Decido colocar el par de llaves público y privado y crear otro par. Entonces ssh-copy-id a través de la Mac, y no, el mismo problema.
En el Mac Mini, en / var / log / syslog, veo:
Aug 25 11:01:59 macmini com.apple.xpc.launchd[1] (com.apple.quicklook[77778]): Endpoint has been activated through legacy launch(3) APIs. Please switch to XPC or bootstrap_check_in(): com.apple.quicklook
Así que solo puedo asumir que al instalar el agente de Zabbix en la Mac Mini, algo cambió.
¿Alguien puede sugerir lo que podría ser y cómo volver a cambiarlo?
EDITAR: la salida de ssh -v
[darren@server ~]$ ssh -v -i .ssh/id_rsa darren@macos
OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to macos [192.168.1.31] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 1
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6
debug1: match: OpenSSH_7.6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'macos' is known and matches the RSA host key.
debug1: Found key in /home/darren/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: .ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 533
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Requesting [email protected]
debug1: Entering interactive session.
debug1: client_input_global_request: rtype [email protected] want_reply 0
Last login: Sat Aug 25 11:51:33 2018 from 192.168.1.11