Newbie question passwords, keys
Scott
I've read the section of the "Red Hat 7.1 Customization Guide" that
deals with ssh clients, but I have a few questions:
http://www.redhat.com/docs/manuals/linux/RHL-7.1-Manual/custom-guide/openssh-clients.html
I'm able to generate DSA keys just fine, but I'm wondering what good is
it? (1) Is entering a passphrase somehow more secure than just using
your password? (2) Is using an empty passphrase a bad idea?
(3) If I set up keys on multiple clients, do I just append each one's
~/.ssh/id_dsa.pub to the end of the ~/.ssh/authorized_keys2 file on the
server? What, with just a space between each one?
(4) If I want root access back on the server, is it better to ssh as
root, or ssh as some user and then su to root?
(5) The Red Hat docs I referenced say that Red Hat uses DSA by default.
Is there any reason to use RSA?
(6) Anybody got any advice regarding security on the default sshd setup
on the server. I haven't changed any config at all, is that going to be
okay?
Any help at all would be greatly appreciated.
Scott
> (3) If I set up keys on multiple clients, do I just append each one's
> ~/.ssh/id_dsa.pub to the end of the ~/.ssh/authorized_keys2 file on the
> server? What, with just a space between each one?
Just wondered if maybe the correct procedure is to just
copy the ~/.ssh/id_dsa.pub to each client I want to use....hmmm
Richard Silverman
"Scott" == Scott <linu...@earthlink.net> writes:
Scott> I'm able to generate DSA keys just fine, but I'm wondering what
Scott> good is it? (1) Is entering a passphrase somehow more secure
Scott> than just using your password?
Even though it looks very similar from a user perspective (entering a
"passphrase" instead of a "password"), public-key authentication operates
quite differently. Principal advantages are:
- Keys are strongly random, as opposed to human-memorized passwords which
are vulnerable to guessing attacks.
- The public-key method does not disclose your key to the server, or allow
the server to use or guess at your key. The password method transmits
your password to the server, so that a compromised server or
man-in-the-middle attack could steal it.
- OpenSSH provides many user-controllable login restrictions if the
authentication method is public-key, via options in the authorized_keys
file. This is not a design advantage of the method, but merely an
(unfortunate) artifact of the software -- but it is a consideration.
Scott> (2) Is using an empty passphrase a bad idea?
Yes, since it is equivalent to storing your password in a file on disk
named PLEASE-STEAL-MY-PASSWORD.TXT.
Scott> (3) If I set up keys on multiple clients, do I just append each
Scott> one's ~/.ssh/id_dsa.pub to the end of the
Scott> ~/.ssh/authorized_keys2 file on the server?
Yes, although you don't need a different key for each host; one ("your
key") will do.
Scott> What, with just a space between each one?
As is documented in the SSH man page, the format is one key per line.
Scott> (4) If I want root access back on the server, is it better to
Scott> ssh as root, or ssh as some user and then su to root?
The latter is generally preferable, since gives better accountability and
is administratively simpler (one place to look/configure for root
access).
Scott> (5) The Red Hat docs I referenced say that Red Hat uses DSA by
Scott> default. Is there any reason to use RSA?
RSA tends to be a bit faster. Also, some people have a principled
objection to the security of the DSA method. Simon Tatham used to have an
explanation of this on:
http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
but it seems to have disappeared.
--
Richard Silverman
sl...@shore.net
Simon Tatham
> Also, some people have a principled objection to the security of the
> DSA method. Simon Tatham used to have an explanation of this on:
>
> http://www.chiark.greenend.org.uk/~sgtatham/putty/changes.html
>
> but it seems to have disappeared.
Yes; PuTTY has had a change of policy and now supports DSA. The
reason for this is that what I thought was an unavoidable weakness
turned out to be possible to get around if you're clever.
If implemented naively and fed by a poor random number generator, a
DSA implementation is capable of giving away enough information in
the signature to deduce the user's private key. PuTTY therefore
avoided ever generating DSA signatures, not on absolute principle
but on the practical grounds that since Windows lacks a proper
entropy collection mechanism, I didn't trust the random number
generator with the task of protecting that valuable a prize.
I've since been informed of ways around this problem; anyone really
interested in the details should see the large comment in PuTTY's
`sshdss.c' (in the dss_sign() function).
So I now (obviously) believe it is _possible_ to implement DSA in a
way that doesn't have this security weakness; but I still wouldn't
choose to trust someone else's DSA implementation if I could choose
RSA instead. The PuTTY documentation still recommends RSA to anyone
whose server configuration allows them to use it.
--
Simon Tatham What do we want? ROT13!
<ana...@pobox.com> When do we want it? ABJ!
Bill Unruh
]Scott wrote:
]> (3) If I set up keys on multiple clients, do I just append each one's
]> ~/.ssh/id_dsa.pub to the end of the ~/.ssh/authorized_keys2 file on the
]> server? What, with just a space between each one?
Yes, you copy the id_dsa.pub key to each client into (append) the authorized_keys2
file
Each one on a new line (not a space but a newline between each entry)