Mac – Endpoint has been activated through legacy launch on Mac Mini

bashmac-miniscpsshunix

Asking this here as I don't think it's a Linux problem.

My Mac Mini sits on a desktop and is the 'central authority' for all of my backups. I have nine Linux virtual machines on a server on which scripts run nightly to do for example, MySQL dumps and to tarball up attachment directories on my Atlassian servers. The resulting backups are then secure copied across to the Mac overnight, and of course, they're then part of the 'TimeMachine' backup and three times weekly, I swap out an external drive to which the most recent deltas are copied, and take that into my office to sit in my drawer.

It's a bit of a 'clunky' solution that has grown up over the years as my knowledge has increased.

Two days ago, I installed a new VM to run zabbix and that's working well. This meant, of course, the installation of the zabbix agent on all of the Linux machines, and I went all out and got it running on the Mac, too.

This morning, I get an e-mail from the Atlassian server, telling me that it could not scp the backups across, as the host key had changed, and warned me that there may be a 'man in the middle attack'. There wasn't, of course, as only one of my servers is public-facing, and that sits behind one firewall, has firewalld running on it and sends all traffic into the network through a small standalone RHEL server on which firewalld is running. But I follow the advice of the e-mail, and I go to the /home/darren/.ssh/known_hosts file and remove the 'offending' line. Just to be sure, I check the backup script, verify that it's using the correct key files (it is – $HOME/.ssh/id_rsa), and run a bare ssh to the Mac. Boom – connected instantly.

I run the backup script manually on the Atlassian server, and rather than transferring the file to the Mac, I get..

Permission denied (publickey).
lost connection

I decide to hose the private and public keypair and create another pair. I then ssh-copy-id them across to the Mac, and nope – same problem.

On the Mac Mini, in /var/log/syslog, I see:

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

So I can only assume that in installing the Zabbix agent on the Mac Mini, something got changed.

Can anyone suggest what it might be, and how to change it back?

EDIT: the output of 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 no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: client_input_global_request: rtype host.ssh-00@openssh.com want_reply 0
Last login: Sat Aug 25 11:51:33 2018 from 192.168.1.11

Best Answer

I figured it out. At the same time as I had installed the zabbix VM, I had also decided to put the /etc/hosts file under ansible control. So every night, the /etc/hosts file was pushed out from the Mac, to all of the Linux VMs. Except that at the top of that file on the Mac was..

127.0.0.1 macos.invalid.com

So when the Linux VMs came to do their nightly backups, the script told them to scp the tarballs to 'macos.invalid.com' which they of course considered as 'localhost'.

Definite 'duhhh!!' moment.

Sorry to have taken your time. That'll teach me to mess with ansible (which, in my defence, does a host of other stuff on my network without causing problems!)...

Related Solutions

MacOS – Mac OS X Lion and sshpass

You should first file a complaint with the server's administration, observing that public key authentication is vastly more secure than simply a password, but I'll assume you've already done so, and your admins are simply idiots.

Apple sadly removed ssh-askpass when they integrated its functionality into ssh, scp, and ssh-add. There is however an SSHKeychain package that provides an ssh-askpass with an Apple-like Cocoa password prompt for macports' openssh package. It should fix your problems the way you want, perhaps even setting the SSH_ASKPASS variable for you.

Just fyi, I'd usually recommend against installing the openssh macports package itself because it break your Apple password prompt, but once you've installed SSHKeychain macports usually offers a more recent openssh than Apple.

There is nothing wrong imho with embedding passwords in scripts when the server disables public key authentication, i.e. if they cared about security, they should reenable public keys. There are even servers that intentionally break sshpass. You could access such machines using the following expect script :

#!/usr/bin/expect -f
set timeout -1
set send_human {.05 0.1 1 .07 1.5}
eval spawn $argv
match_max 100000
expect {
   -re "USERNAME@(\[0-9A-Za-z_\\-\\.\]+)'s password: "
     { sleep 0.1 ; send -- "PASSWORD\r" ; sleep 0.3 }
}
interact

You may speed up this script by reducing the sleeps and send_human delays.

SSH Private Key Permission – Password Dialog Prompt Solution

Make sure you have a corresponding id_rsa.pub or id_dsa.pub in your ~/.ssh directory.

When I had an id_rsa but not a corresponding id_rsa.pub, Mac OS X kept popping up the dialog and remember passowrd in my keychain did nothing.

cd ~/.ssh
ssh-keygen -y -f id_rsa > id_rsa.pub

generated the appropriate public key file for me.

If you already had your public file there (rename it to another name) and generate the public key again using the above command, you'll notice that the generated and the old one are not equal. Somehow the older versions of Mac OS X generated a public key that Lion does not like anymore, generating it again fixes that.

For the curious, the key is exactly the same, the part that changes is that there is no "comments" section after the key on the file any longer.

Best Answer

Related Solutions

MacOS – Mac OS X Lion and sshpass

SSH Private Key Permission – Password Dialog Prompt Solution

Related Question