As the subject says: I'm trying to use putty to replicate a connection that
I originally used under Linux and that used the ProxyCommand directive.
Following all the docs I could find, I'm doing:
in the main window: user@internalpc, port 22, protocol SSH
in the proxy config panel: local proxy, and local proxy command is
This is running under Windows 7. However, when I try to connect, I
immediately get an error "server unexpectedly closed network connection".
It looks putty isn't even trying to do anything.
What I've tried:
- using actual host and port values in place of %host and %port in the
local proxy command: same thing
- running the local proxy command on the command line: works fine, that is,
I see internalpc's SSH banner.
I'm not sure how to debug this. Any help appreciated.
> >This is running under Windows 7. However, when I try to connect, I
> >immediately get an error "server unexpectedly closed network connection".
> What version of PuTTY?
0.62, downloaded from the official page.
> Have you tried specifying the full path to plink.exe and to your .ppk
> file in the "Telnet command, or local proxy command" field?
> I quickly tried this with PuTTY 0.62 on Windows XP with the full path
> (but without the -i); it worked for me.
I hadn't, now I did, and it fails in the same way :-(
I tried both using single backslashes (eg c:\windows\system32\plink.exe,
same for ppk file) and double backslashes (eg
c:\\windows\\system32\\plink.exe, same for ppk file). Just in case, I
tried with forward slashes as well...same failure.
In the meanwhile, I learned about plink -load option, so I tried creating
and saving a putty session for user@externalpc using public key
authentication (which works fine), and then using "plink -load
externalsession -nc %host:%port" as the internal proxy command, but
unfortunately again no joy.
It's instantaneous: I click "connect", and immediately putty's black
window appears, with the error message's white box on top of it ("server
unexpectedly closed network connection"). Just out of curiosity, I tried
running wireshark while I was clicking "connect", it looks like no traffic
at all is produced, I don't even see a SYN packet towards any host!
For what it's worth, this is a 64-bit windows 7 running in a KVM virtual
machine. Are there known issues with some of that?
pk <p...@pk.invalid> writes:
>c:\windows\system32\plink.exe
[...]
>For what it's worth, this is a 64-bit windows 7 running in a KVM virtual
>machine. Are there known issues with some of that?
I suspect that your choice of location for plink.exe is likely to be
your problem.
On 64-bit Windows, the system32 directory is intended for 64-bit
programs. If you put 32-bit programs (such as putty.exe or plink.exe) in
there, they may have problems due to the way the Windows 32-bit
compatibility stuff works.
(I don't know why running plink.exe works for you from the command-line,
as my information about the system32 directory is second-hand, so I
don't know what the nature of the problems you'll run into are.)
If you desperately want to put programs from the PuTTY suite in a
Windows system directory on 64-bit Windows, the right place is probably
c\windows\syswow64 ; better still to put them somewhere else.
<jac...@chiark.greenend.org.uk> wrote:
> pk <p...@pk.invalid> writes:
> >c:\windows\system32\plink.exe
> [...]
> >For what it's worth, this is a 64-bit windows 7 running in a KVM virtual
> >machine. Are there known issues with some of that?
> I suspect that your choice of location for plink.exe is likely to be
> your problem.
> On 64-bit Windows, the system32 directory is intended for 64-bit
> programs. If you put 32-bit programs (such as putty.exe or plink.exe) in
> there, they may have problems due to the way the Windows 32-bit
> compatibility stuff works.
> (I don't know why running plink.exe works for you from the command-line,
> as my information about the system32 directory is second-hand, so I
> don't know what the nature of the problems you'll run into are.)
> If you desperately want to put programs from the PuTTY suite in a
> Windows system directory on 64-bit Windows, the right place is probably
> c\windows\syswow64 ; better still to put them somewhere else.
Thank you! That was indeed the problem. I moved it to another location and
it worked immediately. I wish I found that mentioned in some of the many
pages I read while trying to debug this.
Jacob Nevins <jac...@chiark.greenend.org.uk> writes:
> pk <p...@pk.invalid> writes:
>>c:\windows\system32\plink.exe
> [...]
>>For what it's worth, this is a 64-bit windows 7 running in a KVM virtual
>>machine. Are there known issues with some of that?
> I suspect that your choice of location for plink.exe is likely to be
> your problem.
> On 64-bit Windows, the system32 directory is intended for 64-bit
> programs. If you put 32-bit programs (such as putty.exe or plink.exe) in
> there, they may have problems due to the way the Windows 32-bit
> compatibility stuff works.
> (I don't know why running plink.exe works for you from the command-line,
> as my information about the system32 directory is second-hand, so I
> don't know what the nature of the problems you'll run into are.)
The reason is that the command prompt is a 64-bit executable, so when
it looks for files in c:\windows\system32 it sees the files that are
actually there on the disk. So cmd.exe can quite happily see
everything of any bittedness in c:\windows\system32.
PuTTY is a 32-bit executable. On a 64-bit system, when it is told to
open something in c:\windows\system32, it will actually look in
c:\windows\syswow64 . The upshot of this is that by default 32-bit
executables can't access the content of c:\windows\system32. (In fact
there is a cheaty way to do so, by accessing c:\windows\sysnative
instead.)
pk <p...@pk.invalid> writes:
>Thank you! That was indeed the problem. I moved it to another location and
>it worked immediately. I wish I found that mentioned in some of the many
>pages I read while trying to debug this.
<jac...@chiark.greenend.org.uk> wrote:
> pk <p...@pk.invalid> writes:
> >Thank you! That was indeed the problem. I moved it to another location
> >and it worked immediately. I wish I found that mentioned in some of the
> >many pages I read while trying to debug this.
