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.
How:
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
below.
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 [209.81.27.197] 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