open rdp inside SSH tunnel fails - server windows XP SP3

"remote access to ______________ can not be established. Please check network connectivity and firewall settings on you PC/network"

 

 

 

2012.07.17 13:45:03 -  debug1: server_init_dispatch_20

2012.07.17 13:45:03 -  debug1: Entering interactive session for SSH2.

2012.07.17 13:45:03 -  debug1: monitor_child_preauth: administracao has been authenticated by privileged process

2012.07.17 13:45:03 -  debug1: monitor_read_log: child log fd closed

2012.07.17 13:45:03 -  Accepted publickey for administracao from 1_6.2_5.8_.9_ port 64683 ssh2

2012.07.17 13:45:03 -  debug1: ssh_rsa_verify: signature correct

2012.07.17 13:45:03 -  debug1: restore_uid: 11009/10513

2012.07.17 13:45:03 -  Found matching RSA key: 41:93:d0:3a:8c:5d:5e:a2:f4:ba:92:c3:d9:90:35:35

2012.07.17 13:45:03 -  debug1: matching key found: file /home/administracao/.ssh/authorized_keys, line 2

2012.07.17 13:45:03 -  debug1: fd 4 clearing O_NONBLOCK

2012.07.17 13:45:03 -  debug1: trying public key file /home/administracao/.ssh/authorized_keys

2012.07.17 13:45:03 -  debug1: temporarily_use_uid: 11010/10513 (e=11009/10513)

2012.07.17 13:45:03 -  debug1: attempt 2 failures 0 [preauth]

2012.07.17 13:45:03 -  debug1: userauth-request for user administracao service ssh-connection method publickey [preauth]

2012.07.17 13:45:02 -  Postponed publickey for administracao from 1_6.2_5.8_.9_ port 64683 ssh2 [preauth]

2012.07.17 13:45:02 -  debug1: restore_uid: 11009/10513

2012.07.17 13:45:02 -  Found matching RSA key: 41:93:d0:3a:8c:5d:5e:a2:f4:ba:92:c3:d9:90:35:35

2012.07.17 13:45:02 -  debug1: matching key found: file /home/administracao/.ssh/authorized_keys, line 2

2012.07.17 13:45:02 -  debug1: fd 4 clearing O_NONBLOCK

2012.07.17 13:45:02 -  debug1: trying public key file /home/administracao/.ssh/authorized_keys

2012.07.17 13:45:02 -  debug1: temporarily_use_uid: 11010/10513 (e=11009/10513)

2012.07.17 13:45:02 -  debug1: test whether pkalg/pkblob are acceptable [preauth]

2012.07.17 13:45:02 -  debug1: attempt 1 failures 0 [preauth]

2012.07.17 13:45:02 -  debug1: userauth-request for user administracao service ssh-connection method publickey [preauth]

2012.07.17 13:45:02 -  debug1: user administracao matched 'User *' at line 25

2012.07.17 13:45:02 -  debug1: user administracao matched 'User administracao' at line 12

2012.07.17 13:45:02 -  debug1: attempt 0 failures 0 [preauth]

2012.07.17 13:45:02 -  debug1: userauth-request for user administracao service ssh-connection method none [preauth]

2012.07.17 13:45:02 -  debug1: KEX done [preauth]

2012.07.17 13:45:02 -  debug1: SSH2_MSG_NEWKEYS received [preauth]

2012.07.17 13:44:59 -  debug1: expecting SSH2_MSG_NEWKEYS [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_NEWKEYS sent [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]

2012.07.17 13:44:59 -  debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth]

2012.07.17 13:44:59 -  debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]

2012.07.17 13:44:59 -  debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_KEXINIT received [preauth]

2012.07.17 13:44:59 -  debug1: SSH2_MSG_KEXINIT sent [preauth]

2012.07.17 13:44:59 -  debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]

2012.07.17 13:44:59 -  debug1: Local version string SSH-2.0-OpenSSH_5.9

2012.07.17 13:44:59 -  debug1: Enabling compatibility mode for protocol 2.0

2012.07.17 13:44:59 -  debug1: no match: PuTTY_Release_0.60

2012.07.17 13:44:59 -  debug1: Client protocol version 2.0; client software version PuTTY_Release_0.60

2012.07.17 13:44:59 -  Connection from 186.205.82.94 port 64683

2012.07.17 13:44:59 -  debug1: inetd sockets after dupping: 3, 3

2012.07.17 13:44:58 -  debug1: rexec start in 4 out 4 newsock 4 pipe 6 sock 7

2012.07.17 13:44:58 -  debug1: Forked child 1584.

2012.07.17 13:44:58 -  debug1: fd 4 clearing O_NONBLOCK

 

[Server]

Port=22

Compression=delayed

LogLevel=DEBUG

TCPKeepAlive=yes

LoginGraceTime=120

Protocol=2

MaxAuthTries=6

MaxSessions=10

UseDNS=no

 

[Sftp]

Enabled=yes

SftpMode=internal-sftp

ReadOnly=no

LogLevel=ERROR

LogDestination=eventlog

 

[Options]

EventsTimeWindow=2 days

 

[Commands]

Linux shell and Sftp=-

Sftp=internal-sftp

Linux shell=/bin/bash --login -i

Windows shell=/cygdrive/c/windows/system32/cmd.exe

No shell access=/bin/false

 

[ServiceTypes]

Rdp=3389

Vnc=5900

Sftp=22

SecureWeb=80

Generic=??

 

[Default]

 

[User CAIXA\administracao]

Command=Windows shell

PasswordAuthentication=no

PubkeyAuthentication=yes

AllowTcpForwarding=yes

 

[User CAIXA\agendamento]

Command=Windows shell

PasswordAuthentication=no

PubkeyAuthentication=yes

AllowTcpForwarding=yes

 

[Service rdp]

Type=Rdp

Host=192.168.1.7 

Port=3389

 

local rdp to 192.168.1.7 works

 

by the way, 192.168.1.7 is the portforme copssh server, I've tried also 127.0.0.1 before and the same symptom.

 

Are both client and server XP machines ? Can you establish ssh connection directly ?

Yes, both Windows XP (server and client)

 
also client Windows 7 and server XP
 
if I run the client, it fails but...
 
if I open putty manually, pageant provides the password and I can connect
 
then, if I create a tunnel manually, it works as expected (as the client should have)
 
regards,Yes, both Windows XP (server and client)
 
also client Windows 7 and server XP
 
if I run the client, it fails but...
 
if I open putty manually, pageant provides the password and I can connect
 
then, if I create a tunnel manually, it works as expected (as the client should have)
 
regards,

I've just updated copsshac_plink.exe, copsshac_pageant.exe and mstsc.exe to the latest version.

 

recreated the client using the wizard.

 

failed again, same symptoms.

 

ssh tunnel to rdp manually thru putty works

 

seems that the tunnel is not established / created by the client.

 

in fact the tunnel is indeed created by the client

C:\Users\<username>>netstat -an | find ":30001"

  TCP    127.0.0.1:30001        0.0.0.0:0              LISTENING

  TCP    [::1]:30001            [::]:0                 LISTENING

 

I went to C:\Users\<username>\AppData\Local\Temp\copsshac directory

and double clicked copsshac_mstsc.exe manually

 

then I tried to connect to "127.0.0.1:30001" and the remote RDP was shown to me.

 

 

 

I copied "mstscax.dll" from \windows\system32 to the copsshac directory, inside the "server", the place where the wizard fetch the files to create the client.

 

C:\Arquivos de programas\ICW\copsshac>copy \WINDOWS\system32\mstscax.dll .

        1 arquivo(s) copiado(s).

 

after this, I re-ran the client creation wizard.

 

guess what ?

 

new error message, but a different symptoms...

 

seems to be something related to language / localization

 

it client tries to open rdp, but fails with the following message:

 

"

copsshac_mstsc.exe

O sistema não pode encontrar o arquivo especificado.

c:\Users\windows-username\AppData\Local\Temp\COPSSHAC\<LANG_NAME>\copsshac_mstsc.exe...."

 

translation:  "the system could not find the specified file"

 

after a few retries (guess that 5), it gives up and stops trying.

 

I need a solution for this situation before next monday jul, 23.

 

I can't help you if you tweak PortForMe internals the way you've done. Please create clients as described and trigger the problem.

copsshac_mstsc.exe is not invoked by the client created.

I created a folder "pt-br" inside the path where the execution files are extracted and copied to inside it c:\windows\system32\pt-br\mstsc.exe.MUI as copsshac_mstsc.exe.MUI 

 

when I call the copsshac_mstsc.exe from C:\Documents and Settings\admin\Configurações locais\Temp\COPSSHAC, then the RDP client is shown without error and connects.

 

the wizard is failing to execute / call copsshac_mstsc.exe 

 

I cannot see / observe copsshac_mstsc.exe execution neither from "task manager" nor from "process explorer".

 

I can see child process from copsshac1.exe called copsshac_pageant.exe and copsshac_plink.exe, but there's not a child process copsshac_mstsc.exe .

 

 

 

i can also see a chilld process called "netstat.exe" being executed at least twice, then the error message of connectivity issue is shown.

 

after this, copsshac1.exe dies, but copsshac_pageant.exe keeps running and copsshac_plink.exe also remains running and connected.

 

if I call mstsc.exe and/or copsshac_mstsc.exe and connects to 127.0.0.1:30001 the remote screen is shown, even without copsshac1.exe running.

 

 

 

ok, tweaking is over / undone.

 

portforme uninstalled.

 

temporary files removed.

 

porforme reinstalled.

 

let's start again, from scratch.

 

after reinstalling from scratch, same situation.

 

question:  after connecting with "plink", why "netstat" is executed ?  do you check anything from netstat output ? 

 

only after and if the check is validated, then copsshac_mstsc.exe is called ?

 

can you tell me what it the check done ?  

 

perhaps we're facing a localization / translation issue.

 

"server" and client runs Windows Portuguese - Brazilian (pt-br) 

regards,

 

 

If I create the client using the wizard specifying the IP address instead of the DNS name of the remote server, then the RDP session is shown correctly.

 

If I configure IP number instead of the name at the time of the client creation, then the connection is made and copsshac_mstsc.exe runs and opens the remote screen.

 

waiting for a feedback.

 

 

We can confirm that Client Access wizard works with IP-addresses only. This is a glitch and we will fix it shortly.

is this a problem with copsshac1.exe or anything related with putty tools ?

 

any date for the solution ?

 

any way to solve this locally ?  edit a file ?  registry key ?  

 

 

I noticed that the copsshac_plink.exe uses "-load" parameter, perhaps this is the problem.

per plink.exe documentation, chapter 7.2.1

Chapter7.html#plink-usage-batch

"

...

If you use -load, the saved session exists, and it specifies a hostname, you cannot also specify a host or user@hostargument - it will be treated as part of the remote command.)

...

"

I guess that without -load, would work.

something like this:

copsshac_plink.exe -P 22 -l <username> -i  <keyfile.ppk> -C -noagent -2 -T -N -L 127.0.0.1:<localport>:<remote-internal-host>:<remote-host-internal-port> <hostname>

I tryed here and seems to be working fine (at least running manually).

 

 

any news ?   no news means good news ?

 

PortForMe works with IP-addresses only. One of the reasons behind this decision was to remove DNS-lookup part as a potential attack vector. At the moment, we have no solution for it. However, it is registered as a feature request.