[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Using RSA authentication with SSH - mini HOWTO

On Mon, Sep 11, 2000 at 01:02:18AM -0400, S . Salman Ahmed (ssahmed@pathcom.com) wrote:
> >>>>> "NA" == Nate Amsden <aphro@aphroland.org> writes:
>     NA> if you want to keep 'hackers' out, i suggest using it and
>     NA> disabling password authentication in SSH and force RSA
>     NA> passphrase authentication. of course this requires you have
>     NA> knowledgable users(or you tell them how to create passphrases
>     NA> and stuff)
>     NA> 
> Could you explain the steps necessary to do this ? I am running sshd (v1
> I think) on my home system (woody) which is on a cable connection. I
> would like to able to connect to this home system from work to
> periodically check email, etc.
> I currently use PuTTY at work for ssh connections. How can I setup
> things so that I don't use password authentication ?
> Also, will PuTTY work with a SSH v2 server ?

AFAIK, no.  But Data Fellowes has released a free v2 client for Windows,
or at least announced same.

The following is a brief howto on using RSA key authentication for SSH
sessions which I wrote for use at OpenSales.  Note that the remote host
needs to have RSA access enabled.  This is assumed in the HOWTO, and is
typically enabled by default.

Corrections appreciated.


		How to Use RSA Key Authentication with SSH

Controlling Author:  Karsten M. Self
Fri Aug 4, 2000

What:	Allow secure, authenticated remote access, file transfer, and
	command execution *without* having to remember passwords for
	each individual host you connect to.

Who:	All users needing remote access or data.  All platforms -- SSH 
	is available for Linux, Unix, Windows, and Macintosh

Why:	It's the Right Thing to Do (tm). 

	In a networked world, remote access is a reality we have to deal
	with.  Remembering passwords to myriad systems is inconvenient
	at best, and leads to bad practices at worst -- shared
	passwords, shared accounts, and other evils -- which are a
	significant source of security threats.  

	RSA authentication is both convenient (one passphrase, or if you
	choose, no passphrase), allows access to many systems.  Remote
	actions such as programs and file transfers can be automated so
	that you don't have to "be there" when long processes occur.  If
	access from a specific user or host needs to be curtailed, the
	specific RSA key can be removed from the authorized_keys file
	without requiring password changes of all other users.

	Where accounts *must* be shared, RSA authentication provides an
	additional audit trail and level of control over who is
	accessing the account.  Again, if access from a specific
	location or user needs to be curtailed, the appropriate key can
	be removed from the authorized_keys list without disrupting
	access for other users.


And all of this you can do in three easy steps!

   0. You will need ssh installed on your computer.  

   1. Create a local RSA key:

	   $ ssh-keygen

      Follow the prompts, this takes a few seconds as your computer
      gathers entropy from the system.

      You will be asked to supply a passphrase, you can elect to choose
      a null passphrase.  I would recommend you *do* supply a passphrase
      as it provides additional security -- your key is not useful
      without it.  The upside is that you only have to remember this one
      passphrase for all the systems you access via RSA authentication.
      You can change the passhrase later with "ssh-keygen -p".

      This is typically stored in your home directory under
      .ssh/identity.  After doing this, a directory listing of ~/.ssh
      should look like:

	-rw-------    1 karsten  karsten       528 Aug  4 21:37 identity
	-rw-r--r--    1 karsten  karsten       332 Aug  4 21:03 identity.pub
	-rw-r--r--    1 karsten  karsten     28106 Jul 26 16:52 known_hosts

   1. Copy the public key "identity.pub" to the hosts you wish to access
      remotely.  You can do this by any method you like, one option is
      to use scp, naming the key to indicate your present host:

          $ scp .ssh/identity.pub remote-user@remote.host:local-host.ssh

      e.g.:  I might name a key for navel "navel.ssh".

    2. Connect to the remote host.  You don't have RSA authentication
       configured yet, so you'll have to use an old method such as
       walking up to the terminal or supplying a password.  Add the new
       hostkey to the file ".ssh/authorized_keys". 

         $ cat local-host.ssh >> .ssh/authorized.keys

       Note the use of *two* right-angles ">" -- this will *add* the
       contents of "local-host.ssh" to a preexisting file, or create the
       file if it already exists.

       Check the permissions of .ssh/authorized keys, it *must* be as
       below or you won't be able to use RSA authentication:

	-rw-r--r--   1 karsten karsten    334 Aug 4 21:03 authorized_keys

       And you're all set!

    3. Test the method by logging out of the remote server and trying to
       connect to it via ssh:

           $ ssh remote-user@remote-host

       You may be prompted for your RSA key passphrase, but you won't
       need a remote password to connect to the host.  If you are
       prompted for a password, or your connection is refused, something
       is wrong, and you'll want to refer to the troubleshooting section

You can repeat steps 1 - 3 for each remote host you wish to connect to.

More information:

    o man ssh
    o man ssh-keygen
    o man sshd

Troubleshooting:  If Something Breaks

You get to keep the pieces.

A common error is to have file permissions set wrong somewhere.  

    o Your .ssh directory may be writeable *only* by you, but needs
      group and world read permissions.  
    o Your private key cannot be readable by anyone but you.  
    o Your public key cannot be writeable by anyone but you, but needs
      group and world write permissions.

...problems with any of these permissions may mean you cannot log in to
a system.  The permissions need to be correct at both sides of the
connection.  You can get diagnostics by invoking your connection with
the verbose "-v" flag:

    $ ssh -v remote-user@remote-host

Successful output looks like:

    SSH Version OpenSSH-1.2.3, protocol version 1.5.
    Compiled with SSL.
    debug: Reading configuration data /etc/ssh/ssh_config
    debug: Applying options for *
    debug: ssh_connect: getuid 1000 geteuid 1000 anon 1
    debug: Connecting to bugs.opensales.org [] port 22.
    debug: Connection established.
    debug: Remote protocol version 1.5, remote software version 1.2.26
    debug: Waiting for server public key.
    debug: Received server public key (768 bits) and host key (1024 bits).
    debug: Host 'bugs.opensales.org' is known and matches the host key.
    debug: Encryption type: 3des
    debug: Sent encrypted session key.
    debug: Installing crc compensation attack detector.
    debug: Received encrypted confirmation.
    debug: Remote: Server does not permit empty password login.
    debug: Trying RSA authentication with key 'karsten@angel'
    debug: Received RSA challenge from server.
    debug: Sending response to host key RSA challenge.
    debug: Remote: RSA authentication accepted.
    debug: RSA authentication accepted by server.
    debug: Requesting pty.
    debug: Requesting shell.
    debug: Entering interactive session.
...if you see lines indicating refusals or incorrect permissions, track
down and correct the problem.

Karsten M. Self <kmself@ix.netcom.com>     http://www.netcom.com/~kmself
 Evangelist, Opensales, Inc.                    http://www.opensales.org
  What part of "Gestalt" don't you understand?   Debian GNU/Linux rocks!
   http://gestalt-system.sourceforge.net/    K5: http://www.kuro5hin.org
GPG fingerprint: F932 8B25 5FDD 2528 D595 DC61 3847 889F 55F2 B9B0

Attachment: pgpgGWNym3Vn9.pgp
Description: PGP signature

Reply to: