ssh without sftp ?

[adegomme]

I recently stumbled on a supercomputing center where SFTP server is not running and actually forbidden (executing the server manually is technically possible, but not really an option), while SSH access is otherwise fully functional. I asked, and the underlying idea is to prevent users from using SSHFS and sharing their remote home/work folders without any control. No comment on that, but maybe this policy will be applied by other supercomputing centers at some point.

This prevents Aiida from connecting to the system, as it uses paramiko's sftp client automatically. This raises a few questions about how to proceed in this case.

• Has anyone been affected by this case and found a workaround ?
• Would a "pure" SSH+command mockup of sftp commands used in aiida be possible/a good idea when sftp fails to initialize ? I will begin to toy with this to see if it can work.
• Would it be in another transport plugin, or in the default ssh one, and used as a fallback?
• verdi computer test output was a bit confusing in this case, and could maybe provide a specific test for sftp connexion (obviously system is under maintenance right now and I can't provide the output)? Maybe checking the output of open_sftp() call and returning an explicit error could do the trick to assist the user (I know now that in the doc it's already written to check sftp access).

[adegomme]

update:
I've just managed to get "Success: all 5 tests succeeded" on a cluster without sftp, with pure SSH + shell to replace sftp in all calls that need it (cat+echo to perform the put/get actually do the trick, no idea about performance).

I will try to go further and launch some computation soon, to see if it's robust enough (not yet, I guess).

[greschd]

For moving the files, couldn't you use scp? I guess that shouldn't be blocked, and performance should be acceptable.

In general, the only downside I could see of adding this as a fallback is that users who have SFTP access (but misconfigured for some reason) would not notice, and end up with potentially degraded performance.
In any case I think it's a good idea to start testing this separately (which I guess is what you're doing now), and then we can decide how to integrate it.

[giovannipizzi]

Indeed, it would be probably a wise idea to use this as a different transport plugin (maybe with common code in a base class 'SshBase' and then reimplementing the differences in the two implementations).

Note that with the current implementation, if you try to transfer a file (via STDOUT/STDERR as you will be doing) larger than a few MB, it will probably hang. This does not pop out so often in AiiDA because we typically big transfer files via SFTP ;-)
But you should definitely see it.

I think I fixed this in this PR: #3787 but never managed to properly test it.

I suggest that you try to see if you can transfer "large" files (I think ~50MB is already more than enough), see if it hangs, and then use the implementation of #3787. If you test it and report back that it works correctly (no locks, and no data corruption) we'll merge it.

[adegomme]

So, I finally took the time to do some tests and cleanups.
I'm publishing the transport as a separate plugin (aiida-sshonly, which should be on the repository soon, https://github.com/adegomme/aiida-sshonly ), as we need to install it on some computers soon.

• I confirmed that big file transfers hang and that Avoid deadlocks when retrieving stdout/stderr via SSH #3787 works fine in my case, and seems to prevent hangs for large files with this transport.
• This is (as expected) impacted by exec_command_wait should return stderr and stdout as bytes rather than strings? #3814, limiting it to text files for now. This could prove annoying at some point, but for now we'll do without. I tried a workaround using uuencode/uudecode, but obviously some systems (our main target) don't have these, so that's not an option.
• For now, the plugin ships with an ssh.py file from aiida, with Avoid deadlocks when retrieving stdout/stderr via SSH #3787 fix already included, as well as the changes from Ssh only transport #4235 to make it a "base" class, where the relevant sftp commands can be overriden. Once everything is merged, I will remove this copy and it will use the one from aiida.transports.
• I will make a new PR to see if these small changes can be merged, and close the previous WIP one.

[giovannipizzi]

@adegomme I'm closing this issue since you have released your own plugin to do this. Note that I'm working now on #3787 and #3814, so please monitor those to update your plugin (I'm going to ping you there soon as there is a 'backward-incompatibility' to be taken care of by you after #3787 is merged)