Ssh without passwords

From OpenFSG
Jump to: navigation, search

This assumes you already know how to setup the ssh server and how to log in. It also assumes you've used the ipkg upgrade system to upgrade to OpenSSH instead of the pre-loaded SSH server.

The advantages to having an account that uses a pre-shared key is that it's perfect for backups and other automated tasks.

REMEMBER this is really going to poke a hole through your security though - please know the risks first! Changing the account's password won't stop anyone using a pre-shared key.

This set of instructions assumes you have OpenSSH command lines at both ends - if you have a PC then I recommend Putty [1] - an Apple Mac on OS X should already have OpenSSH available from the terminal (please correct this if wrong).

Contents

Create ssh pre-shared keys

Creating a key in cygwin:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/Matt/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/Matt/.ssh/id_rsa.
Your public key has been saved in /home/Matt/.ssh/id_rsa.pub.
The key fingerprint is:
92:00:37:da:bf:00:55:00:c4:e9:96:7c:d6:86:da:85 Matt@freya


Setting up an account to log into on the FSG

I will use the "admin" account although you may want to use an account with restricted permissions. It's really not a good idea to use "root".

I create the .ssh directory and make sure the permissions are correct:

mkdir .ssh
chmod 700 .ssh

NOTE: If you have version 3.3.9 or above then OpenSSH (by default) enforces strict filesystem restrictions to be 700 for the user's home directory. If permissions are set which allow other users to access it (such as the default, 770), the ssh-daemon will ignore the authorized_keys file in the home directory (note: this applies for the entire directory, not just .ssh). Incidentally, permissions of 744 seem to work, too, but 700 is safer.

If the above is the case, you'll keep wondering why this writeup is not working - and eventually discover the following in your logs:

/ # cd /var/log
/var/log # cat /var/log/messages| grep ssh
<38>Apr  6 06:06:49 sshd[533]: Server listening on 0.0.0.0 port 22. 
<38>Apr  6 06:07:01 sshd[552]: Accepted password for admin from 192.168.1.10 port 50120 ssh2 
<38>Apr  6 06:07:11 sshd[556]: Authentication refused: bad ownership or modes for directory /home/.users/nicolas

There's two ways around this caveat: 1) to set the home-directory permissions to be 700 (or 744) - or to relax OpenSSH's settings.

Method 1: setting home directory permissions (in this example we assume you are using user "admin")

su
cd /home/.users
chmod 700 admin

Method 2: changing OpenSSH's settings

In
/opt/etc/openssh/sshd_config
set the follwing value by removing the # in front of it and change its value
StrictModes no

Method 2 allows you to use this method for root logins since root and admin share the same home directory on FSGs. So this is easy way to get this to work for home-systems - but something NOT to be done to systems connected to the internet or in a business environment...

Adding your public keys to the authorised keys

On your local machine you scp the key up into the FSG user's .ssh tree (adding the FSG to your local known hosts at the same time)

$ scp id_rsa.pub admin@fsg:.ssh/freya.pub
The authenticity of host 'fsg (192.168.1.2)' can't be established.
RSA key fingerprint is 83:00:7c:72:00:40:1d:3a:8a:00:1c:77:d0:95:ab:4f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'fsg' (RSA) to the list of known hosts.
admin@fsg's password:
id_rsa.pub                                    100%  392     0.4KB/s   00:00

Finally you add all the public keys (i.e. you can have more than one system added - just throw their public keys into the FSG .ssh directory before this step):

cat *.pub > authorized_keys


Test it

That should be it! If it's not working then check the permissions on the files in the FSG (chmod 700 them all) and if that fails then switch on logging and LogLevel DEBUG3.

Note that if the home directory or the .ssh directory of ssh user is readable by others, ssh will not use the file authorized_keys for authentication. Check the openssh manual for the mandatory file and directory permissions on openssh.org.

If you're using a commercial version of ssh

If you are using a commercial SSH (ssh.com or F-Secure SSH spring to mind) then you have other problems - incompatible keys that have to be converted to work : See SourceForge guide to SSH

The ssh-keygen utility will convert a key file from a number of formats to the OpenSSH format, including from the SECSH Public Key File Format used by a number of commercial SSH implementations:

ssh-keygen -i -f KEYFILE

PuTTY: PUTTYGEN.EXE can import and convert some key file formats to the proper type. Follow these steps to do so:

  1. Run PUTTYGEN.EXE
  2. Select the 'Import key' option from the 'Conversion' menu
  3. Select the private key that is to be imported, then click the 'Open' button
  4. At this point, you can save the key to the PuTTY .ppk format and the public key can either be copied and pasted from the interface or saved to a file as needed


Automatic logins using putty

Yes there is a way to allow automatic logins using Putty [2] and other ssh clients - see here for more details [3]

Thanks

Thanks to http://ammonlauritzen.com/blog/2006/04/16/shared_key_ssh_authentication/ , Haschi for http://www.openfsg.com/forum/viewtopic.php?p=9404 and http://www.openfsg.com/forum/viewtopic.php?p=11372

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox