Re: [vox-tech] sshd_config and PasswordAuthentication
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox-tech] sshd_config and PasswordAuthentication
on Thu, Jul 07, 2005 at 07:43:52AM -0700, Henry House (email@example.com) wrote:
> P? 2005-07-07, skrev Jay Strauss:
> > Hi,
> > I have a sveasoft box, and in order to ssh from the sveasoft to a target
> > box, the target box must have PasswordAuthentication yes in the
> > /etc/ssh/sshd_config file.
> > I don't understand what that config option actually does. The config
> > file has:
> > # To disable tunneled clear text passwords, change to no here!
> > Does this mean you can send clear text passwords to login?
> > Does this mean that when you build a tunnel, passwords are sent clear
> > text to the forwarded app?
The curious can read the SSH protocols here:
...which I've done. I've been using SSH for years, but only understand
some parts of it vaguely.
> No, SSH never passes password across the net in cleartext. They are
> sent to the remote host when using this option, which means that
> unless you have a different password for each host, a malicious remote
> administrator could capture your password and then use if to
> compromise your other accounts.
In more detail:
- When an SSH session is initiated, an encryption key is negotiated.
This is _prior_ to authentication.
- The client and server exchange lists of supported encryption
ciphers, and decide on one to use.
- A Diffie-Hellman Key Exchange is transacted. From:
The Diffie-Hellman (DH) key exchange provides a shared secret
that can not be determined by either party alone. The key
exchange is combined with a signature with the host key to
provide host authentication. This key exchange method provides
explicit server authentication as is defined in Section 7.
In the following description (C is the client, S is the server;
p is a large safe prime, g is a generator for a subgroup of
GF(p), and q is the order of the subgroup; V_S is S's version
string; V_C is C's version string; K_S is S's public host key;
I_C is C's KEXINIT message and I_S S's KEXINIT message which
have been exchanged before this part begins):
1. C generates a random number x (1 < x < q) and computes e =
g^x mod p. C sends "e" to S.
2. S generates a random number y (0 < y < q) and computes f =
g^y mod p. S receives "e". It computes K = e^y mod p, H =
hash(V_C || V_S || I_C || I_S || K_S || e || f || K) (these
elements are encoded according to their types; see below),
and signature s on H with its private host key. S sends
"K_S || f || s" to C. The signing operation may involve a
second hashing operation.
3. C verifies that K_S really is the host key for S (e.g.,
using certificates or a local database). C is also allowed
to accept the key without verification; however, doing so
will render the protocol insecure against active attacks
(but may be desirable for practical reasons in the short
term in many environments). C then computes K = f^x mod p,
H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K),
and verifies the signature s on H.
The hash H is computed as the HASH hash of the concatenation of the
string V_C, the client's version string (CR and NL excluded)
string V_S, the server's version string (CR and NL excluded)
string I_C, the payload of the client's SSH_MSG_KEXINIT
string I_S, the payload of the server's SSH_MSG_KEXINIT
string K_S, the host key
mpint e, exchange value sent by the client
mpint f, exchange value sent by the server
mpint K, the shared secret
This value is called the exchange hash, and it is used to
authenticate the key exchange. The exchange hash SHOULD be kept
The signature algorithm MUST be applied over H, not the original
data. Most signature algorithms include hashing and additional
padding - for example, "ssh-dss" specifies SHA-1 hashing. In
that case, the data is first hashed with HASH to compute H, and
H is then hashed with SHA-1 as part of the signing operation.
- Once the session key has been established, other data (including
passwords) can be transferred across the now-secure channel. If you
are using password authentication, you are trusting the remote
server (as Henry notes), but you are not susceptible to on-the-wire
> With PasswordAuthentication set to no, SSH-key authentication must be
> used instead of a password. This method uses public/private key pairs
> created by ssh-keygen(1) to authenticate. This is generally considered
> more secure than tunneled-password authencation for reasons than
> someone else can explaim better than I can.
I'll take a stab at it:
- With SSH-key authentication, you're not sending a password to a
host. If you are the victim of a MitM (man in the middle) attack,
you've just shipped a hash based on your private key (and verifiable
with your public key), not a password. Risk of password loss is
- You allow access for a given SSH key with a list of authorized keys
in ~/.ssh/authorized_keys . You can disable access by a given key
simply by deleting or commenting its line in this file.
- Cracking SSH keys is markedly more difficult (and practically:
computationally infeasible) than mounting a dictionary attack on a
password file. Given that on any given multiuser system, some users
are likely to have weak passwords and/or passwords common to
multiple systems (as a rule I try to avoid this), this is a benefit.
- A a server administrator, by disabling password authentication and
requiring SSH-key auth, you are eliminating the possibility that
password disclosure itself will allow unauthorized access to your
system. Eve would have to gain _both_ the private key _and_ its
passphrase to access the system.
- Users can more feasibly create individual SSH keys from different
clients they might connect to a server from, rather than using the
same password. If access from a given client is to be denied, the
corresponding key can be deleted from that user's authorized_keys
file on the server.
- Users can generate new SSH keys and transfer them to the server as
needed, and with considerably less cognitive overhead than trying to
memorize a new password.
- Use of SSH-key auth allows use of ssh-agent. This allows a user to
validate one or more public keys on a client, to be used
automatically in connection(s) to one or more remote server(s). The
result is that passwordless access (once the agent has been loaded)
is available. It's possible to set various parameters, including
timeouts on authentication (similar to sudo), read that fine manual
for details. ssh-agent is a slight trade-off of convenience for
security, but if you're in the habit of locking your workstation
(xscreesaver screen lock) when away from keyboard, it's a pretty
Karsten M. Self <firstname.lastname@example.org> http://kmself.home.netcom.com/
What Part of "Gestalt" don't you understand?
Obviously it's not going to be trivial to run GNOME apps outside
- Adam Hooper, clarifying the topic of GNOME interoperability
Description: Digital signature
vox-tech mailing list