andre-merzky
commented
7 years ago Hey Marc, thanks for moving that thread into a ticket! Let me explain parts of the magic happening here:
We try to optimize connection setup in two dimensions: performance, and number of connections. The former is not really crucial actually, but the second one is, as the number of connections we are allowed to establish is often limited both on client and server side. Coincidentally, we use the same approach for both: connection sharing.
That works like this: whenever a connection is requested by some SAGA component, we set up a master ssh channel towards the target host, and create a slave channel which reuses credentials from the master channel. All subsequent connection requests make use of the same master channel. The credential reuse makes channel setup faster, and different (usually less strict) limits apply to slave channels -- win/win :-)
Now, what I think happens in your case is that the master channel survives the session, and your next application run picks up the master channel with existing authentication and only creates slave channels. This is intentional to some extent, as its fast.
SSH internally keeps track of master channel processes via a socket in /tmp/, whose name we specify like this (simplified):
path = "/tmp/saga_ssh_%s_%%h_%%p.%s.ctrl" % (local_user, remote_user])where %%h and %%p are filled by ssh with target host and port. If no remote_user is specified in the URL or otherwise now known, that part is omitted.
So my guess is that this socket is still around, your second attempt with a different password matches to the same socket name, finds the socket, and creates a slave channel from an existing, authorized master channel. This should be testable by removing /tmp/saga_ssh_* between the runs -- then the second run should fail with an authentication error because of the invalid password.
Can you please check if the above indeed applies? If so, lets then discuss what behavior you would actually expect, and how we can provide it.
Thanks, Andre.
marcoooo
iparask
Hi All, here is a problem related to the 'good way to use password' for ssh saga connexions.
I store in database saga adaptors parameters, saga Service and Context are initialied in a class instantiated from params set up in DB, "let's call it myadaptor.full.path.ClusterOverSSHWIthUserPass.py". This class store saga adaptors params as instances attributes such as:
Now when I set up login / pass / host parameters in DB, and test connection with my connect function, everything goes well.
Later I come back to my backoffice, (even if I restart my web server), I change password to a erroneous one. Try to test connexion, and I still connect to saga.Service...
How could you explain this ? Saga Context logs the new erroneous password still....
I have no idea... does the saga context are store anywhere on my disk ? (I tried to erase .saga directory with no success either). Is this related to the LIFE_TIME parameter automatically set in context to -1 ?
Is there any way clean context each time I call my connect function (which mainly create Service and Context) ?