# SmartMachine SSH public key authentication from a non-root account

This has been documented for Joyent SmartMachines, in particular for allowing users other than root to use SSH public key authentication, but is just as applicable for getting SSH public key authentication to work in general. SmartMachine reference: http://wiki.joyent.com/wiki/display/jpc2/Managing+SSH+Keys#ManagingSSHKeys-MultipleSSHKeys

First create the Unix account on the server, e.g.

[root@im ~]# useradd -g staff -d /home/davek -m davek
128 blocks
[root@im ~]# passwd davek
passwd: password successfully changed for davek


On the server, create the authorized_keys file in the user’s ~/.ssh directory.

On the client, generate an SSH public/private key pair in the ~/.ssh directory of the user you wish to connect as:

davek@mymachine:~/.ssh$ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/home/davek/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/davek/.ssh/id_rsa. Your public key has been saved in /home/davek/.ssh/id_rsa.pub. The key fingerprint is: davek@mymachine:~/.ssh$


Copy the SSH public key up to the server:

davek@mymachine:~/.ssh# scp id_rsa.pub root@xxx.xxx.xxx.xxx:/home/davek/.ssh
id_rsa.pub           100% |*****************************************************************************************************|   401       00:00
davek@mymachine:~/.ssh#


On the server, copy the public key into the target user’s ~/.ssh/authorized_keys file:

[davek@im /home/davek/.ssh]$cat id_rsa.pub > authorized_keys  On server, change file modes for ~/.ssh/authorized_keys to 600, and to the ~/.ssh directory to 700. On the client, change file modes for the ~/.ssh directory to 700, and check that file modes on the private key are set to 600. Test SSH public key authentication: davek@mymachine:~/.ssh$ ssh davek@xxx.xxx.xxx.xxx
Last login: Mon Dec 10 02:41:18 2012 from xxx.xxx.xxx.xxx
__        .                   .
_|  |_      | .-. .  . .-. :--. |-
|_    _|     ;|   ||  |(.-' |  | |
|__|   --'  -' ;-| -' '  ' -'
/  ; SmartMachine base 1.8.1
-'  http://wiki.joyent.com/jpc2/SmartMachine+Base


# System hard freezes with the AMD FX-8350

As an update to my post here, I observed seemingly random freezes on my system upgraded with the AMD FX-8350. The behaviour encountered was a total freeze of the desktop environment, no response to local keyboard nor mouse, no response to attempting to launch a virtual console, no reponse to pings over the network, and no ability to log in remotely. The only way to restore system operation was to perform a hard reset. Interestingly I could also consistently crash the system running a GraphicsMagick benchmark. Additionally, the freezes were OS-agnostic, occurring under both OpenIndiana and Ubuntu Linux.

Looking around online you can find several posts from folks on AMD Bulldozer rigs with very similar issues (such as detailed here), including a few from people who have rather alarmingly downgraded to a Phenom or Intel CPU as a “fix”, after having received advice to alternately update the motherboard BIOS, faff around with multiple BIOS settings, test and replace the RAM, power supply and hard disk, RMA-ing the new CPU (!?), and on and on and on. Most of this didn’t really add up, and similarly my problems were encountered on a system that was hitherto generally stable using an older-generation CPU (the Phenom II X6 in my case).

To cut a long story short, this quite simply turned out to be the motherboard not stably supporting the FX-8350. Although the ASRock 870iCafe 2.0 is an AM3+ compatible part and advertised as being “8 Core Ready” (to the point of specifically claiming compatibility with the FX-8350), the reality is that the latest BIOS release was in December of 2011 – a major red flag. After upgrading my motherboard to a Gigabyte GA-990FXA-UD3 with the recent F9 BIOS, the system is now stable. And yes, this is using the original PSU, RAM, graphics card etc.

For the OpenIndiana readers, the GA-990FXA-UD3 works fine, although don’t expect USB3.0 support:

# AMD “Piledriver” FX-8350 on OpenIndiana

I’ve recently acquired a brand-spanking-new AMD FX-8350 CPU as an upgrade to my Phenom II X6 box. All the recent benchmarks of this CPU seem to fairly consistently point to it being a multithreaded monster. Plus, AMD has dropped the price of the new FX CPUs compared to the original Bulldozer architecture parts – and the icing on the cake is that the upgrade path is as simple as performing a BIOS update on my budget ASRock motherboard, and swapping out the old CPU for the new. Bliss!

So, given that AMD’s Piledriver archtecture might be a bit of an unknown as far as compatibility with Illumos and OpenIndiana goes, how does it fare? Well, the system seems to boot fine and run: here is the CPU as detected by Peter Tribble’s Solview app:

8 cores, running at 4.0GHz – good. Let’s throw half a dozen VMs its way and see what happens:

CPU utilization as measured by Solview is in the foreground. I should mention that this is also with a couple of OpenIndiana Zones running: GlassFish serving up a wiki, and a local BIND resolver.

In the time since I’ve installed the CPU I’ve experienced a couple of system freezes, so I’ve disabled core power saving features in BIOS to see if that changes anything. Yes, this is a new CPU architecture on a development build of an OS, but all in all, it’s working fairly well. Assuming I can iron out any stability issues, the FX-8350 is easily an incredible bargain.

Update 1: After further investigating the system hanging issues, it’s not limited to OpenIndiana, and is also encountered with Ubuntu Linux installed. Further updates to happen as I get to the bottom of this 🙂

Update 2: See here.