A fix to broken SSH key authenticated login after Mac Sierra Upgrade

For Mac OS, I feel that every major upgrade comes with some aftermaths which may cause short term migraine. The first thing to do could be looking up possible solutions from web searches in the hope that someone has figured out how to fix those post-upgrade problems. It reminds me that it would be safer to wait for a few months since every major OS upgrade has been released. The same truth holds for any other OS releases.

Problem encountered:
After the upgrade of Mac OS Sierra, I was unable to login to my linux box from my MacBook via SSH which was supposed to be using key authentication login without typing password.

Instead, I was asked for the passphrase for my key file like ~/.ssh/id_rsa. First of all, I found I forgot my passphrase. Actually, I have not been typing this passphrase for a while since I setup SSH key authentication on my MacBook for convenience.

The solution:
Someone suggests regenerating new key on local machine to resolve this. First thing first, you need to re-enable password authentication from the SSH server.

Another Mac user pointed out that the problem could be originated from the ssh-agent on Mac OS Sierra which is SSH v7.2 as of writing. A possible situation is that the ssh-agent does not automatically load passphrases on the keychain during startup.

To verify this, try the command:

$ ssh-add -l
The agent has no identities.

Clearly, there is no identity information stored in ssh-agent.

Let's store passphrase in your keychain again:

$ ssh-add -K <keyfile>

whereas <keyfile> could be the path like ~/.ssh/id_rsa, or whatever suits you

It will prompt for the passphrase and then will save them to the keychain. However, you might need to remind yourself the passphrase of that particular key file. If you have saved this in Keychain Access before, you can retrieve the passphrase under Keychains: login -> Category: Passwords in Keychain Access app.

You should be able to login again in the good old way of SSH key authentication, but it may not survive the next reboot for whatever reason since MacOS Sierra. Apple's Engineer states that this is expected and it is just re-aligned their behavior with the mainstream OpenSSH in this area. In other words, the stored passphrase for SSH keychain WILL NOT survive next reboot since MacOS Sierra.

You need to run the following command in Terminal again and again when you log back in MacOS Sierra:

$ ssh-add -A <keyfile>

It sounds like an immediate solution but lasts not long enough.

Taking one step forward, you can add a bash script to run SSH command with that particular identity file on your laptop:

#!/bin/bash
echo "Adding identities to SSH agent..."
ssh-add -A 2>/dev/null
echo "Logging in remote SSH server with specific identity file and port number..."
ssh -i <keyfile> -p <port> username@<remote_ssh_server_name_or_ip>

Ultimately, you can first log in your SSH box, re-enable password authentication on SSH server, regenerate a new RSA key on your laptop and then upload it to SSH box as permanent change. The key authentication will work with the newly generated identity file on Mac OS Sierra.

For details, check these out:
http://askubuntu.com/questions/46930/how-can-i-set-up-password-less-ssh-login
http://manpages.ubuntu.com/manpages/trusty/man1/ssh-copy-id.1.html
https://openradar.appspot.com/27348363

To get rid of Firewall warning for particular application in Mac OS X Mavericks

Each time we open up an application which attempts to open a network connection in OS X, a firewall warning will always pop-up (in case you don't turn your firwall off) to ask for action like allowing a connection to be opened.

This might be annoying when you open your favourite app and get blocked by this warning everyday. The reason would be clear when you type the following command in Terminal for a check:

$
$ codesign -dvvvv /path to/your application

You probably received a feedback like this:

/path to/your application: code object is not signed at all

Well, it explains itself properly. You favourite app have not signed with a valid certificate. A valid cerficate, whether self-signed or genuine, should let OS X Firewall bypass the restriction and let the app open up network connection without warning.

You should not do the following steps unless you are pretty sure the app works normal and doesn't trigger any malicious activities, i.e., not a malware.

To generate your self-signed certificate, you can use OS X built-in app like "Keychain Access".

• From the menu "Keychain Access", select item "Certificate Assistant" and then "Create a certificate ...".
• Type in the name of your certificate in Name field and then select "Code signing" in Certificate Type selection box and then click "Create" button to generate new self-signed certificate. 

You may have to create different certificates for different apps so you can identify each one and revoke the certificate for the app in case you don't like it.

Remember the name of the self-signed certificate you created.

To sign the app you like, there are two options:

For single executable file without framework or plugins, you can try:

$
$ codesign -f -s "name of self-signed cert" /path to/your application

For big application (like *.app) with a set of framework or plugins, you should try adding option like --deep to sign every file recursively within that application:

$
$ codesign --deep -f -s "name of self-signed cert" /path to/your application

To verify the details of code signing for this app, you can re-type a command in Terminal like this:

$
$ codesign -dvvvv /path to/your application

This time you will see those signing attributes like Identifier, Hash type, CDHash, Authority and Signed time showing up properly.

After this, you can try opening your favourite app and this time no more Firewall warning should appear.