[Top][All Lists]

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

Re: Re: SSH revised

From: Lluis
Subject: Re: Re: SSH revised
Date: Fri, 24 Mar 2006 16:49:07 +0100
User-agent: Mutt-ng devel-r782 (based on Mutt 1.5.11/2005-09-15)

El Fri, Mar 24, 2006 at 03:44:32PM +0100, Marcus Brinkmann ens deleità amb les 
següents paraules:
>> ok, so:
>> - an ssh server S listens on socket T 
>> - S recieves a petition to login into Anna's account 
>> - S looks up Anna's associated identificator, A
> Yeah.  I am not sure if A should be a globally unique ID or a 
> capability itself.

when talking about identificator, I was really thinking about a capability, 
but there must be a "hashed table" of capabilities (or identificators), 
mapping them through their string identificator

whether it should really be a single number or a capability, in fact is not 
really important for the outlined steps I listed, as it should make no 
difference on the logger, it's up to it how to handle this details (in fact 
I would use a plain identificator, as it conveys no special or implicit 
privileges, and a capability could be "shared" to get acces to other 

>> - S posts (A,E,{T}) to the logger (being E an identificator of the event 
>>   type)
> Yes.
>> - the logger sends a message to the registered clients on events for A
> As a reply message to a "Get next event" operation initiated by A.

right, as I said later, a was thinking in a udev-like way, where there are 
callbacks to external non-running processes (script spawning)

>> - the user logger routes the event to clients registered for type E
>> - the user side ssh server S' recieves T and starts any sort of 
>>   authentication mechanism that it is able to handle 
>> - if the remote client successfully authenticates, S' creates a suitable 
>>   environment for the remote client
> Yes.
>> and the "login" process for the client to the global logger can be a 
>> registration of "classes", each class of event associated with an user 
>> identification (to make all this process administrable through the 
>> classical ways of user add and remove from groups)
> I don't understand this.  What do you want to administrate?

I think I meant that you could give a user access to some class of events 
just through a 'useradd <user> <group>', as every event-class is associated 
with a valid group of recieve-waiting users (and having a "special" 
capability related to a user is like being part of the group that user 
stands for, if I understood your last mails about groups)

>> [...]
>>> The basic mechanism must be the same, as there should only be one 
>>> mechanism for this.  So, in the end, it will boil down to "one 
>>> capability" that is provided by the system to the user.  However, I think 
>> a local login could be handled by another client logger handler, giving a a 
>> "full powered" environment (if you want it to give it to you)
>> what I don't like is differentiating on this level between local terminal 
>> logins and remote ssh logins... both should be just an EV_LOGIN, with some 
>> properties which differentiate their idiosyncrasies
> The same logion event type can be used.  The difference is in the 
> content of the "directory" that contains the information about the 
> terminal, ie the terminal type (set of logical and physical devices). 
> The user will need drivers for any interesting combination (the system 
> can provide default drivers).

right, and one of the things that should be there is a capability to the 
socket through which the connection is going on (or maybe a cap. to a 
wrapper for the connection, as it could be mirrored)

what confuses me is when you talk about directories... I know it's the 
same, but I better understand it like a cap. bundle (that, in the end, is 
probably all accessible through just one cap.)

>> well, if the client logger is able to spawn a handler that spawns a new 
>> environment/shell, then the system has to do nothing but the username 
>> handling and routing
> Well, and host authentication and transport layer management.

yes, I just "obviated" (is it correct?) this (this is why I talked about a 
socket wrapper a few lines upwards)

>> the problem I see in here, is, what happens when an invalid username is 
>> given? is there a dummy ssh handler to avoid leaking information?
> The list of user names is not secret.  If you really want, you could 
> make a dummy user that rejects all authentication attempts.

isn't it? for me it should be, the knowledge about a username being 
available or not on a system can give me information enough to try a 
directed attack to that account... that's related to why finger disappeared 
as a publicly available service on many of the systems out there... (yes, 
finger gives us much more information than just a username)

>>> In other words: Terminals consist of physical or logical devices that 
>>> the user needs to know how to use.  For SSH, there will be some funny 
>>> logical device, that is not a PTY, but represents an existing SSH 
>>> connection, with channels and what not.
>> I don't completely understand what you try to say here, many things get 
>> away from me :)
> A terminal is a directory which contains capabilities to physical and 
> logical devices, and information about these devices.  The SSH 
> terminal would ocntain different devices than a physical terminal with 
> a video card and keyboard etc.

right! this is a more generalised way of talking about it than what I 
pointed out on the pseudo-something that I wrote at the beginning of my 
last mail (the "S posts (A,E,{T}) to the logger", where {T} tries to 
indicate an array of caps. that will be available to the client logger, who 
will rearrange with, probably, some more caps. from itself)

Read you,

 "And it's much the same thing with knowledge, for whenever you learn
 something new, the whole world becomes that much richer."
 -- The Princess of Pure Reason, as told by Norton Juster in The Phantom
 Listening: Lacrimosa (Echos) - 08. Die Schreie Sind Verstummt

reply via email to

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