Re: [Isms] TBD secshell

[Wes Hardaker <wjhns1 at hardakers.net>]

DH> tmSecurityName is set to "alice" by TSM. SSHTM is the place where the
DH> requested tmSecurityName "alice" is overridden, and ahopkins is chosen
DH> as the user name.
[...]

JH> You're making this all too complicated, I think.

I agree!

Your (David H's) original message on the subject stated:

DH> I think the EOP needs to be modified to make sure the message
DH> processing model can match the outgoing transportaddress for a
DH> request and the incoming transportaddress from the response, which
DH> is how the MPM determines which application is waiting for a
DH> response.  If the request was sent using a user at foo.com address,
DH> then SSHTM uses parses the address into a foo.com address and uses
DH> foo instead of the tmsecurityname specified by the security
DH> model. When we get a response from user at foo.com, we need to make
DH> the TM pass the MPM a transport address of the user at foo.com format,
DH> and set the tmsecurityname to match what was requested by the
DH> security model.


There is only two cases to consider when talking about the SSHTM:

1) The SSHTM is acting as an SSH server.  IE, it was invoked from afar
   and in this case the securityName used within the SNMP system will
   match exactly the SSH user name.  Nothing confusing to behold.  When
   the SSHTM creates a transportAddress for the connection in order to
   pass it upward through the SNMPv3 stack it doesn't need to be
   anything more complex than the remote host address, ':' and port
   number.  The prepended SSH user name and '@' is not needed because
   it's equal to the securityName.

2) The SSHTM is acting as a client.  IE, it is initialized from the
   upper SNMPv3 stack and is handed a transportAddress to talk to.  It
   either will contain a "user@" type string or it won't.

   a) If it does not, again there is nothing much to consider as complex
      because the SSH user name will be identical to the securityName.

   b) If it does contain a "user@" type prefix, it should use that
      within the SSH protocol for identifying itself
      SSH-user-name-wise.  This is where your problem comes in, and this
      is the only case that you think is confusing (right?), in
      particular when a response comes back.

      So, when a response comes back across the SSH connection, the
      SSHTM has to hand the message upward with a transportAddress.
      Your statement above indicates that you think the transportAddress
      passed upward should be prepended with "user@" also.  That's fine
      by me, but I'm not sure why you think it's complex to get the
      right address created.

      The easiest solution is to cache the transportAddress that created
      the session and always use it when passing messages upward to
      through the SNMPv3 stack.  done.  It also assures that the upper
      SNMPv3 stack (specifically, your concerns with decisions in the
      MPM) aren't affected by reverse name lookups not matching the
      outgoing name, or IP addresses not matching DNS names, or whatever.

DH> I don't think it will be terribly difficult to update the EOP, but I
DH> am not sure where the TM stores the request-state (tmsecurityname)
DH> that it must restore when it gets the response.

In the same place it caches all the other information it needs to about
a given SSH connection.
-- 
Wes Hardaker
Sparta, Inc.