Previous Thread
Next Thread
Print Thread
SSH in Windows10 requires "run as administrator" #30929 16 Feb 17 07:25 AM
Joined: Dec 2007
Posts: 48
J
Jason Maxwell Offline OP
Member
OP Offline
Member
J
Joined: Dec 2007
Posts: 48
Since Windows10, on some computers, but not all, the user is required to "run as administrator" on the ATE icon, if their profile is setup to use SSH to connect. otherwise you get an error message:

ATE SSH Transport Error
ATE failed to open SSH connection

Has anyone out there seen this problem ?

Re: SSH in Windows10 requires "run as administrator" #30930 16 Feb 17 08:56 AM
Joined: Jun 2001
Posts: 11,925
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,925
No one has reported this.

BUT: I've just managed to reproduce it. (It seems to happen only for all-users profiles that are launched from a normal user context.)

The immediate workaround is to create a new version of your configuration that is for the current user only.

But hopefully I'll have a better answer for the all-users case after studying it...

Re: SSH in Windows10 requires "run as administrator" #30931 16 Feb 17 09:13 AM
Joined: Dec 2007
Posts: 48
J
Jason Maxwell Offline OP
Member
OP Offline
Member
J
Joined: Dec 2007
Posts: 48
As always, you are correct. If I change my "all users" to "current user" my problems go away.

including the email thing.

thank you so much.

Re: SSH in Windows10 requires "run as administrator" #30932 16 Feb 17 10:11 AM
Joined: Jun 2001
Posts: 11,925
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,925
I've also found the real problem, which has to do with the accessing the SSH fingerprint in the registry (which is a necessary step in validating the connection). In the case where the fingerprint is new, typically the user is prompted to authorize it (unless you checked the Auto Accept Fingerprint option in the ATE config) and then the new fingerprint is written to the registry. But in the case where you have an all-users configuration, the normal user doesn't have write privileges. I'm going to modify it to not ask for write privileges, which won't solve every problem, but should allow you to get by if the fingerprint matches (or if you have the auto accept option set).

But, if I'm going to update the ashnet2.dll module for this, I might as well do a complete pass through all the related sub-modules (openssl, zlib, etc.) That may take a day or so. And, probably the new ashnet2.dll will only make it into 6.3/6.4 (although it could probably be manually copied into the 6.2 bin directory.)

I'll follow up when that's ready...

Re: SSH in Windows10 requires "run as administrator" #30933 16 Feb 17 10:23 AM
Joined: Jun 2001
Posts: 11,925
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,925
BTW, there should be an ashnet2.log file in your ATE directory which would presumably contains something like the following...

AshNet2 Ver 206 SSH connect to 192.168.253.134:22 login=jack, cfg=VMware-CentOS 7 (ssh all)
Unable to access registry key SOFTWARE\MicroSabio\JBCT\ATE\Hosts\VMware-CentOS 7 (ssh all)

Re: SSH in Windows10 requires "run as administrator" #30934 16 Feb 17 11:57 AM
Joined: Jun 2001
Posts: 11,925
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,925
Here's an updated version of the ashnet2.dll that should allow a normal user to make the SSH connection using an all-users configuration without being administrator. You can just replace the existing ashnet2.dll with it...

ashnet2-2.3.207.zip

Re: SSH in Windows10 requires "run as administrator" #30935 20 Feb 17 06:08 AM
Joined: Jun 2001
Posts: 11,925
J
Jack McGregor Online Content
Member
Online Content
Member
J
Joined: Jun 2001
Posts: 11,925
Note: The ate-6.3.1544.7-web.exe installer/updater contains a further update to the SSH protocol support (in ashnet2.dll 2.3.208). Aside from updating the dependent OpenSSL and related libraries, it also closes a minor security loophole related to the all-users configurations.

The issue here (as described earlier in this thread) is that the all-user profiles are stored in an area of the Registry that is read-only to non-admin users. That works nicely in cases where an administrator sets up a profile to be shared by multiple users and you don't want one user messing up those shared settings. (They can still save the user-level customizable settings, such as initial window size and position, color palette, etc., via the File > Save menu.)

But the problem was that the SSL protocol involves comparing a fingerprint on the server with a saved copy of that fingerprint on the client, to guard against the possibility that the server has been spoofed or redirected to somewhere unexpected. In such a case, a dialog will be displayed warning the user of the change and asking them if it is ok to accept and update the fingerprint. In the previous patch (2.3.207), we allowed the non-admin user to indicate approval even though he didn't really have the privileges necessary to actually save the new fingerprint. Now, in such a case, we deny the connection.

Which makes security sense, even if it may be a slight hassle in operating environments were you don't really worry about that fingerprint changing. If that seems like a step backwards to you, the solution is simple: just check the Auto-Accept Fingerprint option in the configuration. In that case, it pays no attention to the fingerprint.


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3