UQWorld

UQ dispatcher connection failed

Hello! I’ve been using UQLab for a while on my local machine but with the changes in 1.4 I’m very keen to be able to submit jobs on my university HPC. I should say I’m not great with UNIX and my understanding of SSH is very sketchy. All of the requirements on host (linux) and client (windows) side seem to be met, I successfully installed UQLab on the host server and I have a saved PuTTY session that connects to the HPC using SSH keys. In case its relevant - I have to use a tunnel to get to the HPC server itself since I’m not on the campus network, and this is all configured in the saved PuTTY
session. I’ve set up my DispatcherOpts using the basic template and tried to execute uq_createDispatcher but the connection times out. If I open cmd and run e.g. plink -T mysessionname it connects just fine. Running plink -T -ssh mysessionname does not work. I tried adding DispatcherOpts.SSHClient.SecureConnectArgs = ‘-T’; to remove the -ssh flag and then running uq_createDispatcher again but this throws another error:
Error using uq_Dispatcher_init_checkSSH (line 55)
SavedSession mysessionname
can’t be used to connect to the remote machine.
As I’m sure you can tell, I’m blindly trying things without really understanding the problem, does anyone have any ideas what might be the problem?
Many thanks!
Sebastian

Hi @s_rosier,

Welcome to UQWorld!

What would running the following command in the command prompt gives you?

ECHO test | plink -T mysessionname "exit 0"

Could you perhaps try it? Thanks a lot! :slight_smile:

Hi @damarginal , thanks for the speedy reply! I should have mentioned I actually tried a few variations of this already… if I try what you suggest there is a brief pause and then the text prompt reappears, so no error message but no output as such, not sure how to directly check the exit code or if I should expect this to be printed to the console… :thinking:

If the command runs successfully, there should not be any output (that echo was just a leftover code inside the Dispatcher module, but should not create a problem).

I think, you can check the exit code of a command execution from the command prompt using the pseudo environment variable %errorlevel%, so in the prompt:

> echo %errorlevel%

right after the previous plink command above.

And while you’re at it, how about executing the same command from MATLAB using the system function:

system('plink -T mysessionname "exit 0"')

Ah hah that’s good to know! trying this command after running the plink command returns a 1, which is also what I get when I run this using the system command in matlab. Removing the ‘echo |’ part of the command in the windows command prompt, i.e. just plink -T mysessionname “exit 0” results in a message ‘Access granted. Press Return to begin session’.

It’s a bit curious that the system command returns 1 (non-zero exit status indicating something’s wrong), that’s why the SSH check failed. You can see the message produced by the terminal if you assign the second output of system to a variable like this:

[exitStatus,msg] = system('plink -T mysessionname "exit 0"')

I’m not sure echo causes the problem, but you can try.

When i try running your suggested command to see the message it just returns a 0x0 empty char array :frowning_face:

When you connect to the remote machine, do you have access to the shell of the remote machine? What happen when you press enter after being granted access (using PuTTY or plink without passing the "exit 0" command to the remote)?

The Dispatcher relies on the ability to send shell commands (such as exit 0) from the local machine to the remote machine via SSH. I’m not sure, but maybe it’s got something to do with the tunnel setting (?). Perhaps somehow the command is rejected…

Thanks for persisting - I think we’re getting warmer! This should have occurred to me, when I hit enter after gaining access nothing happens, I’m still in cmd on the local machine. Same when I try to load the PuTTY saved session in PuTTY itself, it runs, a command window briefly opens with no error messages and then closes again. Could this be a problem with the way I’ve configured the session or could it be a security setting on the remote server that’s not allowing me to do what I want? I normally access the server using MobaXTerm on my windows machine or directly from the console in MacOS and here I can of course run commands on the remote server.

It’s been a while since I used MobaXTerm for Windows, so I have to check it out again. If you can make a connection that opens a remote shell with MobaXTerm, I don’t think there’s a reason you can’t do the same with PuTTY.

In the meantime, perhaps you can double check if the settings you use to make a connection using MobaXTerm is really equivalent to the one you put in the PuTTY saved session (making changes after saving and forgetting to save again are quite common). Finally, you can check if PuTTY actually gives any message when you try to open a session that’s got closed immediately by checking the box Never on Close window on exit in the main window of PuTTY configuration (see the bottom of the window).

BTW, what’s the command you use to make a connection to using ssh command (I assume) on Mac (please anonymize all important tunnel setting/ip address/username in your reply :slight_smile:)?

I compared the two but I don’t see any obvious differences in any settings. When I prevent putty from closing the window on exit I see the following:
authenticating with public key “name of key”
Last login: time and IP of last login
then a popup message: connection closed by remote host.
On my Mac I just type in ‘ssh server_name’ and I previously configured my .ssh/config file as follows:

Host *
ForwardAgent yes
ForwardX11 yes

Host gateway_server
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

Host server
User server_username
IdentityFile ~/.ssh/id_rsa
HostName server_hostname
ProxyCommand ssh -W %h:%p -p gateway_port_number gateway_username@gateway_server 2> /dev/null

Apologies for posting twice, I’m still looking for some way to get this working. It seems this may be a problem with PuTTY, I wonder if I can access the server using a tunnel without using a PuTTY saved session?