Chiedendo questo qui perché non penso che sia un problema con Linux.
Il mio Mac Mini si trova su un desktop ed è l''autorità centrale' per tutti i miei backup. Ho nove macchine virtuali Linux su un server su cui gli script vengono eseguiti ogni notte per fare, ad esempio, i dump MySQL e installare le directory degli allegati sui miei server Atlassian. I backup risultanti vengono quindi copiati in modo sicuro sul Mac durante la notte e, naturalmente, fanno parte del backup "TimeMachine" e tre volte alla settimana, sostituisco un'unità esterna a cui vengono copiati i delta più recenti e nel mio ufficio per sedermi nel mio cassetto.
È una soluzione un po '"goffo" che è cresciuta negli anni man mano che la mia conoscenza è aumentata.
Due giorni fa, ho installato una nuova VM per eseguire zabbix e funziona bene. Ciò ha significato, ovviamente, l'installazione dell'agente zabbix su tutte le macchine Linux, e sono andato tutto fuori e l'ho fatto girare anche su Mac.
Questa mattina, ricevo un'e-mail dal server Atlassian, che mi informa che non è stato possibile eseguire il backup dei backup, poiché la chiave host è cambiata e mi ha avvertito che potrebbe esserci un "attacco uomo nell'attacco centrale" . Non c'era, ovviamente, come solo uno dei miei server è pubblico, e che si trova dietro un firewall, ha firewalld in esecuzione su di esso e invia tutto il traffico nella rete attraverso un piccolo server RHEL standalone su cui è in esecuzione firewalld. Ma seguo il consiglio della e-mail, e vado al file /home/darren/.ssh/known_hosts e rimuovo la riga 'offendente'. Per sicurezza, controllo lo script di backup, verifica che utilizzi i file di chiavi corretti (è - $ HOME / .ssh / id_rsa) ed esegui un ssh nuda sul Mac. Boom: connesso all'istante.
Eseguo manualmente lo script di backup sul server Atlassian e invece di trasferire il file sul Mac, ottengo ..
Permission denied (publickey).
lost connection
Decido di ingurgitare la coppia di chiavi privata e pubblica e creare un'altra coppia. Poi li metto su ssh-copy-id attraverso il Mac, e no - lo stesso problema.
Sul Mac Mini, in / var / log / syslog, vedo:
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
Quindi posso solo presumere che nell'installare l'agente Zabbix su Mac Mini, qualcosa sia cambiato.
Qualcuno può suggerire cosa potrebbe essere, e come cambiarlo?
EDIT: l'output di 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