« Return to Thread: Proposed SSH Transport Address Changes (and a quick nit)

Re: Proposed SSH Transport Address Changes (and a quick nit)

by Juergen Schoenwaelder-2 :: Rate this Message:

Reply to Author | View in Thread

On Tue, Jul 15, 2008 at 11:37:28AM -0700, Wes Hardaker wrote:

> >> snmpwalk -u schoenw ssh:juergen@...:1234 ifTable
>
> JS> Not sure I understand this. For me, this means "authenticate as
> JS> 'juergen' at host.example.com" but then what do I use 'schoenw' for?
> JS> The TM security name is going to be 'juergen' and assuming no further
> JS> mappings, this will be the securityName on the agent. So where do you
> JS> think 'schoenw' is going to be used?
>
> What I was proposing is different.  The passed in securityName and the
> securityName that would associated with the session is unmodified.  It
> would still be "schoenw".
>
> The SSH username passed via the SSH authentication scheme would be
> "juergen" though, allowing the local "schoenw" user to log into
> "juergen" on the remote machine.  This occurs all the time today when I,
> as "hardaker" log into another machine as "whardaker".  For my proposal,
> only the SSH transport needs to know about the remote username in the
> address specification.  The local session would still hold "schoenw" as
> the local securityName attached to the session.

For command generators, the local security name (schoenw in the
example) is kind of pointless. If I use ssh:juergen@...,
then the authenticated identity on the command responder side is
juergen.
 
> The only real added benefit is to allow notifications to be sent to
> multiple remote destinations with different remote user names that are
> all mapped to the same VACM entries locally for notification
> authorization.

Yes, once we talk about notifications, things are different since
access control is applied to the local user identity.

> David's already against the idea and I'm fine with dropping it as
> well in interest of forward progress.  It's a minor twiddle to the
> document and I'd be happy to supply wording if support beyond myself
> is found.  Either way, it should probably be a MAY support, IMHO.

I am fine with being silent enough about this to get things out and to
see what gets implemented and deployed.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
Isms mailing list
Isms@...
https://www.ietf.org/mailman/listinfo/isms

 « Return to Thread: Proposed SSH Transport Address Changes (and a quick nit)

LightInTheBox - Buy quality products at wholesale price!