Key Based SSH Login Tutorial

First off, this is based on a portion of number3's Tutorial to setup 2 mbwe with rsync over the internet


You have a basic setup already accomplished that includes changing the default "admin" password.
Changing this password is potentially very important as this may be an easy way to compromise your drives.
More on this later.

This does not require any Optware packages at this time.

Create Keys:

On each drive we need to create the key.

cd ~
mkdir .ssh
cd .ssh
ssh-keygen -b 4096 -N '' -t rsa -f id_rsa

Due to a "feature" in the white light drive firmware with permissions you also must run the following 3 commands on each drive in order for ssh via key to work:

chmod go-w ~/
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Copy Keys to "remote" system:

Now we put it into the authorized_keys file on the remote drive.

cat ~/.ssh/ | ssh root@<ip-or name of other drive> 'cat >> .ssh/authorized_keys'

Security Discussion

Now because we have an easily predicable root password for SSH it is potentially very desired to disable password authentication.
Security considerations are potentially very important, and if the drive contains business information it is strongly suggested you discuss these with a security professional.
An in depth discussion of the legal issues/security concerns are beyond the scope of this tutorial but some considerations are:

If the drive is internet accessible this is almost definitely NOT an acceptable risk to leave passwords enabled.
If the drive is only accessed behind a firewall it is possibly an acceptable risk to leave passwords enabled.
If there is a separate (read: not using the mbwe) vpn used to access the drive when not on location it is possibly an acceptable risk to leave passwords enabled.
If the network the drive is on has unencrypted wireless on it then it likely NOT an acceptable risk to leave passwords enabled.
If the network the drive is on has WPA2 based encrypted wireless on it then it is possibly an acceptable risk to leave passwords enabled.

If your think you need to disable ssh passwords read on, if not stop here you are done.
Of course the reverse side of this issue is potentially true that you can accidentally lock yourself out of your device, or that you compromise the security of your device.

Setup Telnet as a backup

First off Telnet is ALWAYS unencrypted including the password used for it which means anything you do with it can be seen by others and therefore it is important to understand there is security issues with using it.

Since we are planning to disable the SSH userid/password logon later on, we want to make sure we have a second way into the box. So logon to your hacked mybook using PuTTY. From now on I will assume that you will sudo to root every time you logon, or you directly logon to the root account.

So you are in? Then go and edit inetd.conf to enable the Telnet daemon.

# vi /etc/inetd.conf

Find the line that reads as:

#telnet  stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd

Now remove the # in the front of telnet:

telnet  stream  tcp     nowait  root    /usr/sbin/telnetd       telnetd

Save your changes, now you have a working telnet daemon. You should NEVER forward to port 23 from the internet router and do not put the mybook box in a DMZ configuration of your network router.

Hardening the SSH configuration

So now our next step is to harden the SSH configuration, we do this to by editing the configuration file ((/etc/ssh_config}}.

#       $OpenBSD: ssh_config,v 1.19 2003/08/13 08:46:31 markus Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for various options

 Host *
   ForwardAgent no
   ForwardX11 no
   RhostsRSAAuthentication no
   RSAAuthentication yes
   PasswordAuthentication no
   HostbasedAuthentication yes
   BatchMode no
   CheckHostIP no
   AddressFamily any
   ConnectTimeout 0
   StrictHostKeyChecking no
   IdentityFile ~/.ssh/identity
   IdentityFile ~/.ssh/id_rsa
   IdentityFile ~/.ssh/id_dsa
   Port 22
   Protocol 2
   Cipher 3des
   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
   EscapeChar ~

Lets now configure the SSH configuration file in such a way that it will no longer accept a password. It should ONLY work with the rsa keyfile we created. These are the options that are used to set it up.
  • PasswordAuthenication set to no, so passwords are no longer used.
  • HostbasedAuthentication set to yes, so the RSA key will now be used to logon to the other computer.
  • StrictHostKeyChecking set to no, this way ssh will not complain when the hostname changes
  • CheckHostIP set to no, this way ssh will not complain when an up address has changed of one of the known hosts.
  • Protocol set to 2, this means that you can only use ssh version 2 protocol. No fallback allowed.

For more information check out the ssh_config manual.

After you changed this, you will need to reboot. The only way to login after this point is to use Telnet if you enabled it…. or by adding an extra rsa key to the authorized_keys file in the home directory. In case you use a Windows box and you use PuTTY, then you start using Pageant. This is the PuTTY agent, that keeps your keys for logging into mybooks.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License