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

XRDP via SSH session

To make use of Windows Remote Desktop Client to connect to Graphical X session on Ubuntu Linux server, there are three basic components that would help make a secured connection:

XRDP server

SSH server

VNC server

XRDP protocol would be used to forward VNC session to Windows RDC. For security reason, it will be done through the data encapsulation by using SSH tunnel.

The benefit is that it doesn't require the client to install VNC viewer and use standard Remote Desktop Client on Windows computer.

For better security, Putty will be used to create SSH connection first and do the port forwarding as follows:

For example:

Port 5555 (client port, any other port than 3389 or 3390) => localhost:3389 (remote server port)

On the server, Firewall rules restrict that only SSH port is open to the users for connection. Through SSH session, we can connect it with Windows RDC by using URI like:

localhost:5555

Before all these happen, we need to make sure that SSH server, VNC server and XRDP server are installed  and configured properly on Linux server.

Use the following commands to install all required servers:

$ sudo apt-get install openssh
$ sudo apt-get install vnc4server
$ sudo apt-get install xrdp

Just skipped SSH and VNC setup whereas you could find lots of references on the other forums.

For XRDP, we need to make a little adjustment on the file "/etc/xrdp/xrdp.ini" .

Depending on the setup of vnc4server, you need to define the VNC port to be forward by XRDP protocol. Under the section "xrdp1" in the file "xrdp.ini", please comment out the line of "port=-1" and add a working VNC port for use, i.e., port=5901.

[globals]
bitmap_cache=yes
bitmap_compression=yes
port=3389
crypt_level=low
channel_code=1

[xrdp1]
name=sesman-Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
#port=-1
port=5901

Then restart XRDP service:

$ sudo service xrdp restart

Now, it's time to test from the client side by initiating SSH connection using Putty client.

Then open Remote Desktop Client on Windows comptuer with the URI:

localhost: 5555

You should a GUI login screen for xrdp session. Using linux username and password, you can login to VNC session like what a VNC viewer normally does.

Enjoy your RDC!

Remotely unlocking LUKS encrypted root partition via SSH

It has been a while since famous DropBear script invented and became Ubuntu package for streamlining the unlocking mechanism of encrypted partition remotely from client computer.

Recently, an inspiring article has been found for a practical approach to this special feature. Of course, it might involve some manual operations during the server reboots and wait for your input to unlock it.

A working solution tested on Ubuntu 9.10 Karmic Koala:

Assuming you have an Ubuntu machine with fully encrypted partition, and you would like to unlock this partition during the boot-up but you are not sitting there in front of the machine. Definitely, you can do it somewhere with another computer.

On Ubuntu machine:

To setup Dropbear SSH Server:

$

$ sudo apt-get install dropbear busybox

Please remind that the package like early-ssh is not required in this case and it is assumed that a working OpenSSH server has been installed and running properly.

Latest version like Ubuntu 11.04 might have problems with the original dropbear script and requires manual modification. It is recommended to refer to  this link for more information.

Now update INITRAMFS:

$

$ update-initramfs -u

It's time to enable the root account in Ubuntu whereas only root user can login Dropbear SSH Server successfully.

$

$ sudo passwd root

You must take extra precaution while enabling root account can lead to security issue on your OpenSSH service. It is recommended to disable root login for OpenSSH by changing the following lines in /etc/ssh/sshd_config.

# change in /etc/ssh/sshd_config

PermitRootLogin no

This is useful in preventing the outsider trying to login as root.

Within the timeframe of DropBear SSH session, the root account is effective anyway. After the unlock operation is finished, DropBear will let the regular OpenSSH server to take over and retires gracefully. Therefore, you may expect DropBear session to be disconnected after you enter correct passphrase to unlock the partition. Then you will need to login again with its OpenSSH session instead.

Before restarting the machine, it is necessary to copy the private key out of Dropbear SSH Server.
A reference command would be like this (assuming you use Linux client to connect to Ubuntu machine):

#Use SCP to copy a certificate from remote machine to local Linux machine
scp user@remote.server:/etc/initramfs-tools/root/.ssh/id_rsa ~/.ssh/remote_dropbear_id_rsa

If you are using Windows client, then you can download WinSCP to copy the file directly onto your desktop. You might notice that an error occurs while you are copying due to file permission. This means you need to set a proper file permission of id_rsa on Ubuntu machine before you copy it out.

After that, reboot your Ubuntu machine and wait for the prompt of passphrase. However, Dropbear SSH Server will also loaded up behind the scene and wait for the authenticated client to enter passphrase remotely. Who is the authenticated client? That might be the one holding the private key generated by Ubuntu machine.

On Client computer:

Assuming you use Windows client to connect and you will need two pieces of software to make it work
Putty.exe
Puttygen.exe

Basically, comprehensive package of Putty includes both of these executables once you download and install its Windows installer from here.

Native Linux generated private key needs to be converted to .PPK file for import in Putty client. That's why we need Puttygen.exe. For instructions, please refer to this link under the section of "Converting the OpenSSH private key to Putty format". To login remotely with the converted private key, please refer to the section of "Logging in Openssh using id_rsa.ppk".

When Ubuntu machine is rebooted and pending for passphrase input, you can login from the client computer remotely with Putty.exe with a proper private key. Bear in mind that you need to login as root user into DropBear SSH console.

Once you login successfully to Dropbear console, you can enter the passphrase from there with a script command:

$

$ echo -ne "**encryptionpassphrase**" > /lib/cryptsetup/passfifo

whereas **encryptionpassphrase** is the required passphrase to unlock the encrypted partition.

You may not notice anything over the console. If the passphrase matches, Ubuntu machine will unlock the disk partition and start to load up at the other side. You can close Dropbear console and then login again into the OpenSSH console of Ubuntu machine with you regular user account from the client computer.

Note: An issue has been experienced regarding IP address distributed by DHCP server. To prevent a different IP address allocated to Ubuntu machine after reboot. It is necessary to setup static IP configuration to make sure IP address unchanged even after Dropbear SSH server loads up. Please refer to this link for more information.