Squeezebox SSH public key authentication

Squeezebox Controller/Radio/Touch SSH Login with Public Key Authentication

Sometimes you may wish to log in to SqueezeboxController, Squeezebox Touch, or Squeezebox Radio to access a command prompt or to copy applets and other files to the device (through scp).

When SSH is enabled on the device, you can log in as user 'root', password '1234'. This password is not very secure, and you should probably log in to the device and change it. But even with a secure password, it is a hassle to enter passwords each time you log in to the device.

A solution to this problem is to use /public key/ SSH authentication. This authentication method is supported by the Dropbear SSH server that the Controller/Radio/Touch hardware runs.

Once you've enabled public key authentication you can log in using your own private key file. Depending on how you've configured your client you may need to put in your passphrase to unlock your key. The advantage here, though, is that the passphrase is chosen by you, and not the insecure '1234' default password.

Getting public key authentication working on the remote involves two steps:

1. Generate your SSH public and private keys (if you've not already got some handy that you want to reuse).
2. Install your public key onto the Controller hardware.

Generating an SSH public and private key

/StuartH: something like the instructions in the following:/

http://sial.org/howto/openssh/publickey-auth

For PuTTY users

• Use the PuTTYgen Tool from the PuTTY Website http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html.
• Generate the keys.
• Save the private key to a file.
• Copy the public key from the memo box into the clipboard or save to a file.
• All you have to do in your PuTTY session is to add the private key file in Connection|SSH|Auth.

Installing your public key onto the Controller/Radio/Touch hardware

/StuartH: These notes could do with expanding./

If you are using a Unix-like OS (Linux, Mac OS, Cygwin on Windows), you can install the key with one long (complicated) command like the following (replace the IP address and identity key file name as appropriate), which will non-destructively set up the Controller/Radio/Touch to accept your keypair:

cd ~/.ssh && cat identity.pub| ssh root@10.1.2.3 "cat > /tmp/authorized_keys; chmod 0700 /root; mkdir /root/.ssh; touch /root/.ssh/authorized_keys; cat /tmp/authorized_keys >> /root/.ssh/authorized_keys; chmod -R go= /root/.ssh"

• Make sure the root directory has the correct permissions (the SSH server is fussy - if permissions look suspicious then public key authentication is disabled).

chmod 700 /root

• Create a SSH directory for your public key to live in, and give it the correct permissions.

mkdir /root/.sshchmod 700 /root/.ssh

• Copy your public key to the following file:

/root/.ssh/authorized_keys

Alternatively you can edit the file with vi:

vi /root/.ssh/authorized_keys

• Press 'i' for insert
• Paste the clipboard.
• Press 'ESC' to exit insert mode.
• Enter ':wq' to save the file and quit vi.

That should be enough. The /authorized_keys/ file should look something like the following (this text should be all on one single line):

ssh-rsa ABAAB3NzaC1yc2EAAAABJQAAAIEAhm/04ZTdAiRh8hAAlUPsLscjxJGcyRfr9GUNpkAcxgMsmSFX781JaByPvF60bwiOUKITLyL+YxXlLgkf3x9BSTW2INlQEqrrk1OfiiWTL2VWE3TFE5NssanB5S3mBaSNzRLg9sH4iVAJRBEwdNZDfekzzVo9frb52ars8QZszYU= My Key

Troubleshooting

If you're having trouble getting this working then examining the logs from your SSH client and server will usually reveal the problem.

Troubleshooting the server

On the server you can watch the log with:

tail -f /var/log/messages

You should see log messages like the following if things are working:

Oct 15 21:40:29 (none) authpriv.info dropbear[160]: Child connectionfrom 192.168.100.3:46101
Oct 15 21:40:30 (none) authpriv.notice dropbear[160]: pubkey auth succeeded for'root' with key md5 11:22:33:44:55:66:77:88:99:88:77:66:55:44:33:22from 192.168.100.3:46101

If you see lines like the following then you've not set up the permissions correctly:

Oct 15 20:59:16 (none) authpriv.info dropbear[123]: /root must be ownedby user or root, and not writable by others

Troubleshooting the client

On the client you can log in verbosely with the following (assuming a command-line SSH client):

ssh -vl root 123.123.123.123

You should see lines like the following if everything is working:

OpenSSH_4.7p1, OpenSSL 0.9.8f 11 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.100.8 [192.168.100.8] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/identity type -1
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version dropbear_0.48
debug1: no match: dropbear_0.48
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host '192.168.100.8' is known and matches the RSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:26
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
debug1: Next authentication method: publickey
debug1: Offering public key: My Key
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.