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:
- Generate your SSH public and private keys (if you've not already got some handy that you want to reuse).
- Install your public key onto the Controller hardware.
Generating an SSH public and private key
/StuartH: something like the instructions in the following:/
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 firstname.lastname@example.org "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:
Alternatively you can edit the file with vi:
- 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
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: Child connectionfrom 192.168.100.3:46101 Oct 15 21:40:30 (none) authpriv.notice dropbear: 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: /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 184.108.40.206
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.