Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Using a local proxy with putty fails immediately
647 views
Skip to first unread message
pk
Jan 26, 2012, 6:45:29 AM1/26/12
to
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
plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
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.
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
plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
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.
Jacob Nevins
Jan 27, 2012, 6:55:40 AM1/27/12
to
pk <p...@pk.invalid> writes:
>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
>
>plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
>
>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?
>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
>
>plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
>
>This is running under Windows 7. However, when I try to connect, I
>immediately get an error "server unexpectedly closed network connection".
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.
pk
Jan 27, 2012, 7:28:02 AM1/27/12
to
On 27 Jan 2012 11:55:40 +0000 (GMT), Jacob Nevins
> 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?
Thanks!
<jac...@chiark.greenend.org.uk> wrote:
> pk <p...@pk.invalid> writes:
> >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
> >
> >plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
> >
> >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.
> pk <p...@pk.invalid> writes:
> >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
> >
> >plink.exe -i privatekey.ppk user@externalpc -nc %host:%port
> >
> >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?
> 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 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?
Thanks!
Jacob Nevins
Jan 27, 2012, 8:43:48 AM1/27/12
to
pk <p...@pk.invalid> writes:
>c:\windows\system32\plink.exe
[...]
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.
>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
>machine. Are there known issues with some of that?
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.
pk
Jan 27, 2012, 10:18:09 AM1/27/12
to
On 27 Jan 2012 13:43:48 +0000 (GMT), Jacob Nevins
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.
Thanks again.
it worked immediately. I wish I found that mentioned in some of the many
pages I read while trying to debug this.
Thanks again.
Owen Dunn
Jan 28, 2012, 6:00:48 AM1/28/12
to
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
> 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.)
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.)
http://msdn.microsoft.com/en-us/library/aa384187(v=vs.85).aspx has
some more of the gory details of how file system redirection works on
64-bit Windows.
(S)
Jacob Nevins
Jan 30, 2012, 6:51:11 AM1/30/12
to
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.
It's now in the PuTTY FAQ (since a few people have run into it):
>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.
<http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-system32>
pk
Jan 30, 2012, 7:13:40 AM1/30/12
to
On 30 Jan 2012 11:51:11 +0000 (GMT), Jacob Nevins
Thanks!
"C:\WINDOWS\SYSTEM32 is intended to contain only 64-bit binaries; Windows'
32-bit binaries live in C:\WINDOWS\SYSWOW64".
Misleading to say the least, if you ask me (I'd expect exactly the reverse).
But we're talking windows after all.
"C:\WINDOWS\SYSTEM32 is intended to contain only 64-bit binaries; Windows'
32-bit binaries live in C:\WINDOWS\SYSWOW64".
Misleading to say the least, if you ask me (I'd expect exactly the reverse).
But we're talking windows after all.
wyrm....@gmail.com
Apr 11, 2015, 5:38:06 AM4/11/15
to
On Saturday, January 28, 2012 at 2:00:48 PM UTC+3, Owen Dunn wrote:
> 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.)
Oh thanks man. Found this answer after trying to use plink with Kitty to access inner servers over gateway for maybe an hour.
> 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.)
My old habits had me put plink into system32 to access it by name without full path.
Thank you.
0 new messages