login about faq

I have setup the tectia SSH Server on a hpcworkstation1 (using Windows HPC Server 2008 R2) , with the settings below:

  • Windows logon type: Network
  • Resolve client hostname: no
  • Windows terminal mode: Console

  • Two nodes: Windows HPC Server 2008 R2 (hpcworkstation1 is joined to the cluster domain) and (hpcheadnode2 is a cluster headnode)

  • Tectia Server ver: 6.2

When submitting jobs from a Linux SSH client to the hpcworkstation1:

ssh user@hpcworkstation1 job submit /scheduler:hpcheadnode2 hostname

Could not connect to the scheduler. The user may not be authorized to connect to the scheduler or the scheduler service might not be running.

However, if I log into the hpcworkstation1 using Remote Desktop, and submit the same job

C:Usersuser>job submit /scheduler:hpcheadnode2 hostname

Job has been submitted. ID: 8808.

How to submit jobs from Linux when Tectia SSH server is installed on non-headnode machine (but joined to the cluster domain)?


asked Aug 29 '11 at 13:18

pageup's gravatar image


edited Aug 31 '11 at 04:57

Hi pageup,

I am not really sure, but it could have something to do with the logon type. This page: LogonUser() explains that with "Network" logon type credentials cashing is not used. That could mean that Windows OS may not be able to find credentials necessary for some operation. Do you have any particular reason for using Network logon type? Could you try the same task with setting the logon type to Interactive?

The authentication method used may also play a role on a Windows server (unfortunately). Could you try the same with password authentication if you have used publikey authentication or certificates, please?

Is the user “user” local or domain user?

A bit out of topic: this may not be well documented, but “Windows terminal mode” only has effect for “terminal” sessions. It has no effect when remote command, like in your example, is executed.

I wish my answers would help in some way

With regards



answered Sep 08 '11 at 22:46

Martin%20Dobsik's gravatar image

Martin Dobsik ♦

Hi, Thank you for your answers!

I use "Network" logon type because tecita documentation says that this "enables accounts that do not have the access right to log on locally".

I have tried different combinations of settings as you have advised, and found that using logon "interactive" without public-key authentication will work. However, if public-key authentication is used, choosing "network" or "interactive" will encounter the same problem.

(Sep 15 '11 at 09:59) pageup pageup's gravatar image

I assume that the user you are logging in with is a domain user. There are are 2 things that come to my mind that can be the issue:

1) It could be that the user's acces token generated by non-interactive authentication methods is different from token generated using password interactive method (it is a very common practice in windows to represent a user in many different ways, in fact giving him many identities). This token may have more limited rights. So the scheduler (or the job command whatever that is) may be trying to access some resources and it may not have rights to do so. So you could try to find out which resource that is and adjust access control list so that it would work (it could be pipe, registry entry, file, ...).

2) Or it could be as Lukasz Tomczyk suggested on another site, that someting in your job command requires access to resources outside of the one machine. In that case you would be practically out of luck with non-interactive authentication method in Windows. As we have learned recenty from MS support people: they just don't support (and don't want to support!) something like this in execution model that Tectia server uses with non-interactive authentication methods. You could still try to configure constraint delegation so that Tectia server would use S4U authentication instead of SSHDAP custom Lsa authentication package. That may or may not help. Here is a link with instructions how to set it up: http://answers.tectia.com/questions/553/how-do-you-access-shared-network-folders-in-a-windows-2003-domain-when-using-public-key-authentication. But that article is obsolete, since Microsoft recently confirmed to us that such use case is not supported and if it happens to work, then just by sheer luck. But it is worth trying, many people are using it. Tectia may provide some other solution to this problem (or rather workaround as Microsoft just does not want to go that way) in the near/far future.

In any case you could change your command to use Tectia client which allows to specify password on command-line:

> sshg3 --password=very_secret_password user@hpcworkstation1 job submit /scheduler:hpcheadnode2 hostname
> sshg3 --password=file://file_that_contains_password.txt user@hpcworkstation1 job submit /scheduler:hpcheadnode2 hostname
> sshg3 --password=extprog://program_that_prints_the_passwrod user@hpcworkstation1 job submit /scheduler:hpcheadnode2 hostname

Please let us know here if you find the solution that works. I don't have experience with HPC servers myself, so I don't know what is the command:

job submit /scheduler:hpcheadnode2 hostname

exactly doing. So if you would explain what is that command actually doing in detail we could, perhaps, think of some more specific things to do.


answered Sep 15 '11 at 22:53

Martin%20Dobsik's gravatar image

Martin Dobsik ♦

Hi, thank you for your answer. I have followed the instructions in http://answers.tectia.com/questions/553/how-do-you-access-shared-network-folders-in-a-windows-2003-domain-when-using-public-key-authentication, select Use any authentication protocol, but this solution does not work.

The job submit command will contact the job scheduler in another node for submitting job. As you have mentioned, the token assigned to the logged-on user (when public key is used, SSH server uses SSHDAP custom Lsa authentication package to authenticate ) may not have enough privilege to access the job scheduler.

Specifying password on command-line with sshg3 may work, but this is not secure enough in our use case.


answered Sep 19 '11 at 12:15

pageup's gravatar image


edited Sep 19 '11 at 12:17

If you are using a public key that is not protected by passphrase (private key is stored in plaintext on disk in this case) and if you would use strong passwords instead, then storing the password to file (with proper permissions/access control lists) is as secure as the public key authentication is. But if you have PIN/passphrase protected keys or even certificates, then it is more secure of course.

There may be a middle ground solution if that is acceptable to you: Tectia SSH serves can be configured so that they will only let user in if he/she authenticates with multiple authentication methods. Therefore, you can configure the server to require to authenticate first with public key and then with password. User is logged in only if both methods pass; in this case with the token generated by password authentication method. We have tested this in situations similar to yours. If the security is the only problem, then this could work for you as the security should be only increased by such solution.

I will still try to ask people if the issue you have could be solved some other way.


answered Sep 20 '11 at 14:26

Martin%20Dobsik's gravatar image

Martin Dobsik ♦

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported



Asked: Aug 29 '11 at 13:18

Seen: 7,356 times

Last updated: Sep 20 '11 at 14:26

All user contributed content licensed under the cc-by-sa license.
Powered by OSQA.