>>>>> "FD" == Frank Dekervel |Smartlounge| writes:

FD> hello, i'd like to have ssh access to a certain server limited to
FD> a number of laptops. Because they are laptops without fixed ip
FD> address, i cannot use hosts.allow and hosts.deny.

FD> Also, hostbased auth doesn't work, as i want normal password /
FD> pkey authentication in addition to this "limit-to-laptops"
FD> measure.

FD> I'd like to do this: only hosts with a public HOST key that is
FD> listed in some file can connect at all. After they succeed to
FD> connect, they should authenticate in a normal way.

The only userauth method in which the client's host key is involved, is
hostbased.

--
Richard Silverman
res@qoxp.net

Richard E. Silverman wrote:

> The only userauth method in which the client's host key is involved, is
> hostbased.

that's a pity ... an option to augment pass/pkey auth with client host key
auth would make brute-force attacks a lot less effective (and i see a lot
of them these days)

greetings,
frank

>>>>> "FD" == Frank Dekervel |Smartlounge| writes:

FD> Richard E. Silverman wrote:
>> The only userauth method in which the client's host key is
>> involved, is hostbased.

FD> that's a pity ... an option to augment pass/pkey auth with client
FD> host key auth would make brute-force attacks a lot less effective
FD> (and i see a lot of them these days)

I don't see how. Brute-force attacks on publickey userauth are not done,
because they are infeasible. Also, there is no point in using hostbased
in addition to publickey -- especially with mobile clients -- because
hostbased is weaker: it relies on the client host being correctly
administered and not compromised, since the server trusts its
identification of the user.

I also don't see much point in combining password and publickey userauth.
Publickey is so much stronger, the addition of a password makes little
difference. In order to steal a user's private key, an attacker must
be in a position to steal the user's passphrase -- in which case, he can
just as easily steal a password as well.

--
Richard Silverman
res@qoxp.net

Richard E. Silverman wrote:

> I don't see how. Â*Brute-force attacks on publickey userauth are not done,
> because they are infeasible. Â*Also, there is no point in using hostbased
> in addition to publickey -- especially with mobile clients -- because
> hostbased is weaker: it relies on the client host being correctly
> administered and not compromised, since the server trusts its
> identification of the user.
>
> I also don't see much point in combining password and publickey userauth.
> Publickey is so much stronger, the addition of a password makes little
> difference. Â*In order to steal a user's private key, an attacker must
> be in a position to steal the user's passphrase -- in which case, he can
> just as easily steal a password as well.

i'm sorry, i didn't express myself correctly. our situation would be "host
based + password auth". I think this is certainly more secure than just
"password auth".

In our setup, we cannot disable password auth: we host multiple websites on
one host, each with its own ssh account, which is mainly used to scp files.
However, only 3 or 4 people really do the scp'ing. Setting up key-based
auth for every ssh account would be a lot of work and hard to maintain.
Currently, we use password authentication. We'd like to make our approach
more secure.

thanks for your comments,
greetings,
frank