[Top][All Lists]

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

Re: SSH revised

From: Marcus Brinkmann
Subject: Re: SSH revised
Date: Tue, 28 Mar 2006 10:41:02 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 28 Mar 2006 09:47:40 +0200,
Bas Wijnen <address@hidden> wrote:
> Allowing a user to log in using ssh opens possibilities for attacks, which
> means that the user needs to be (more) careful for his password, for example.
> If a user doesn't actually want to use the service anyway, it is sensible to
> disable it.  The Hurd way to do this is from the user settings (by not
> registering with the system ssh server, for example).

Or rather: By ignoring log on events that contain a terminal emulated
by the ssh server.

Or in the other example, with virtual domains: By not accepting the
connection in the first place.

> Companies in particular aren't very fast in adopting new methods, though, and
> they'll want to have the administrator do these things.  If the user doesn't
> agree, she can easily work around this if she does have access to the network.
> But I think that trying to tell this to the manager is something that takes
> years (and if we take that effort anyway, we could better tell about something
> important, like software patents ;-) ).

Company policies are not necessarily a good guidance for (our) system

> But as I said, it's easy to disable this.  Depending on how the service is
> implemented, the host ssh server can filter the password file before checking
> if a user is in it, or the administrator can fail to give a capability for the
> network port that should run the server.

What password file? :)

You are right of course, that the feature can be added.  However, I am
really interested in exploring the user freedom principle here.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]