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

Tackling missing SSL intermediate keychain certificate issue on Apache

One of my clients has been complaining about an error message like the one below when they visit some secured web sites via HTTPS protocol on the browser, particular Mozilla Firefox.

The certificate is not trusted because no issuer chain was provided.
(Error code: sec_error_unknown_issuer)

Firefox is well-known open source web browser which has been sticking with W3C standard. For HTTPS tunnel initialisation, Firefox checks through public certificates down to root certificate in order to tell the user whether the connection is completely secured. Among those certificates, the intermediate keychain certificate was ignored in the past by the web browsers. It's not hard to imagine some browser may even automatically try to search and put back this missing piece into the keychain store.

Somehow, it might be difficult to draw a fine line between the responsibility of browser's developer and website administrator. However, there is still something Web Administrator can do to resolve this.

Assuming you are hosting Apache webserver for the target website, try the following URL to check whether there is any problem with the SSL certificates installed on the target website:

https://www.sslshopper.com/ssl-checker.html

Once an error of missing intermediate keychain certificate is found, it's time to proceed to next step for checking which intermediate certificate to install on webserver.

Visit the target website and click on the lock icon to get more information about the SSL certificate already installed. From the certificate information, check the name of issuing authority in order to identify which SSL provider and package you are using.

Go to the website of SSL provider and find relevant intermediate keychain certificate which is supposed to be opened to the public for downloading.

The file content should be something like this:

-----BEGIN CERTIFICATE-----

ENCRYPTED TEXT...

-----END CERTIFICATE-----

Once you've got the intermediate keychain certificate, you can reconfigure Apache to use it to complete the keychain for HTTPS validation.

On hosting server, find Apache SSL configuration file like httpd-ssl.conf and add a line (in red) to specific the intermediate keychain certificate for use:

SSLEngine On
SSLCertificateFile /TargetPath/somedomain.crt
SSLCertificateKeyFile /TargetPath/somedomain.key
SSLCertificateChainFile /TargetPath/intermediates_keychain_cert.crt

When finished, please restart Apache server and then test the secured URL (https://...) of target website with Firefox again. If all certificate and key files are in place on webserver, the error message should go away.