Operating System - Linux
1748274 Members
4172 Online
108761 Solutions
New Discussion

sftp routing through proxy server

 
SOLVED
Go to solution
Abhzi
Advisor

sftp routing through proxy server

Hello Experts,

 

I need an urgent help. I have to make sftp connection to the remote server where I have to put and get files. Using "put" and "get".

 

But I am unable to login to sftp site on internet from my local server.

 

[root@test1 ~]#  sftp -o "ProxyCommand /usr/bin/nc  -X 10.105.54.134 8080 %h %p" User@files12.server.net
Connecting to files12.server.net...
nc: unsupported proxy protocol
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer

 

Please help

 

8 REPLIES 8
Matti_Kurkela
Honored Contributor

Re: sftp routing through proxy server

The "nc" command is reporting an error: "unsupported proxy protocol".

 

Looking at the nc man page, your command syntax seems incorrect. The -X option (upper-case X) requires the name/number of a proxy protocol: 4 for SOCKSv4, 5 for SOCKSv5, and "connect" for using a HTTP/HTTPS proxy.

 

The proxy address and port are specified using another option: -x (lower-case x).

 

The proxy port number 8080 suggests you're trying to use a HTTP or HTTPS proxy.

So, please try this:

 

sftp -o "ProxyCommand /usr/bin/nc -X connect -x 10.105.54.134:8080 %h %p" User@files12.server.net

 

MK
Abhzi
Advisor

Re: sftp routing through proxy server

thanks MK for your reply!

 

but still I am facing the issue. I am not sure whether it is SOCKSv4 or SOCKSv5, so I tried with both and same error.

 

[root@test1 ~]# sftp -o "ProxyCommand /usr/bin/nc -X SOCKSv5x 10.105.54.134:8080 %h %p" User@files12.server.net
Connecting to files12.server.net...
nc: unsupported proxy protocol
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer

[root@test1 ~]# sftp -o "ProxyCommand /usr/bin/nc -X SOCKSv4 x 10.105.54.134:8080 %h %p" User@files12.server.net
Connecting to files12.server.net...
nc: unsupported proxy protocol
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer

 =================================================

 

How ever when I used like below it's hung..no message at all

 

[root@erptest1 ~]# sftp -o "ProxyCommand /usr/bin/nc   -x 10.105.54.134:8080 %h %p" User@files12.server.net

 

User@files12.server.net Connecting to files12.server.net...

 

 

 

 

Abhzi
Advisor

Re: sftp routing through proxy server

with -x 4 and -X 5...command hung.

 

But with -X connect it gave me output like below.

 

[root@erptest1 ~]# sftp -o "ProxyCommand /usr/bin/nc -X connect 10.105.54.134:8080 %h %p" User@files12.server.net 22

 

Connecting to files12.server.net...
nc: Proxy error: "HTTP/1.1 200 Connection established"
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer

 

 

Please suggest

Matti_Kurkela
Honored Contributor

Re: sftp routing through proxy server

> Connecting to files12.server.net...
> nc: Proxy error: "HTTP/1.1 200 Connection established"
> ssh_exchange_identification: Connection closed by remote host
> Couldn't read packet: Connection reset by peer

 

Looks like the proxy is a HTTP/HTTPS proxy, then. A SOCKS proxy would never answer with a HTTP protocol response.

(It's still possible that the 10.105.54.134 server might also contain a SOCKS proxy, but if it's there, it's in some other port. The proxy software in port 8080 looks definitely like a HTTP/HTTPS proxy. The "standard" proxy port number for a SOCKS proxy would be 1080.)

 

The "HTTP/1.1 200 Connection established" is not really an error: "HTTP/1.1" is the protocol version, 200 is the HTTP status code meaning "request was successful", and "Connection established" is the expected message when opening a proxy connection using the HTTP CONNECT method. Maybe the nc command is displaying it as a "proxy error" because the connection was suddenly broken from the remote end, and that was the only information nc received from the proxy?

 

That would mean the connection from your sftp client to the proxy was successful and the proxy is trying to establish a connection to the files12.server.net server, but the files12.server.net server (or a firewall between the proxy and the files12.server.net server) is rejecting the connection.

 

You might want to contact the administrator of that proxy server. Ask him/her if the proxy server has SOCKS proxy functionality too, and if it does, the correct proxy port number for that. Then ask him/her to try connecting from the proxy host to the files12.server.net host, like this:

ssh -v User@files12.server.net

 If the proxy server can talk to the files12.server.net server, the result will be a rather long list of diagnostic messages.

Even if the connection is rejected because the files12.server.net allows only SFTP and nothing else, the diagnostic messages should indicate whether the basic SSH connection was successfully established before the rejection or not.

 

If the proxy server does not have a SSH client installed, the "telnet" command can also be used as a testing tool. If the basic network connection between the proxy and the files12.server.net is successful, the SSH/SFTP server at the other end will display its version identification, like this:

$ telnet files12.server.net 22
Trying files12.server.net...
Connected to files12.server.net.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.0p1 Debian-4

<press Enter here>

Protocol mismatch.
Connection closed by foreign host.

 

Also, your command lines don't seem to be accurate as posted. I'm guessing you made a typo. Please copy&paste the exact command lines you used, if possible: sometimes tiny details are very important.

 

The command:

> sftp -o "ProxyCommand /usr/bin/nc -X connect 10.105.54.134:8080 %h %p" User@files12.server.net 22


should have caused an error message "nc: port number invalid: files12.server.net", because the -x option is missing.

The "22" at the end of the command line is also meaningless: the sftp command does not expect a port number at the end of the command line like that, and 22 is the default port number for SFTP anyway.

 

 

MK
Abhzi
Advisor

Re: sftp routing through proxy server

yes taht was a typo MK! I ran again correctly but it's the same

 

[root@erptest1 ~]# sftp -o "ProxyCommand /usr/bin/nc -X connect -x 10.105.54.134:8080 %h %p" User@files12.server.net

Connecting to files12.server.net...
nc: Proxy error: "HTTP/1.1 200 Connection established"
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer

 

I checked it with my network guy on call, it is  HTTP/HTTPS proxy only and on port 8080.

 

As you say that it looks connection from my server was successful, but the next line error

 

" ssh_exchange_identification: Connection closed by remote host"

 

any RSA key to be mentioned while doing SFTP?

Matti_Kurkela
Honored Contributor

Re: sftp routing through proxy server

ssh_exchange_identification does not refer to any RSA keys: it is the first step in establishing a SSH/SFTP connection. At that point, the server should be reporting its version number and SSH implementation name (e.g. OpenSSH), so that the client can automatically apply workarounds if that particular server software version is known to have bugs. Then, the client will also report its version number and implementation name, so that the server can do the same.

 

When a proxy is involved, your sftp client opens a TCP connection to the proxy using a specific proxy protocol (HTTP CONNECT, in your case), and tells the proxy system the ultimate destination of the connection. The proxy will then open a second TCP connection between itself and the destination (and informs that this connection was successfully opened), and allows data to flow from your connection to the new one, and vice versa. The proxy should not participate to the SSH/SFTP encryption or connection negotiation in any way. So, after this initial set-up, your sftp client expects to be able to use the TCP connection to the proxy as if it was connected directly to the destination host.

 

But in your case, for some reason known only to the destination server, the destination server chooses to immediately close the connection instead of reporting its version number.

 

Such behavior (i.e. the connection closes immediately after opening) is typical when the destination server uses tcpwrappers and/or libwrap to protect the connected service, and the connecting host is not on the allowed list (typically /etc/hosts.allow, but may be different). There may be other reasons for such behavior too.

 

In your case, you should remember that as far as the destination host knows, your connection to it is coming from the proxy's IP address, not from the IP address of the client system.

If this connection is passing through the public Internet, the proxy's IP address 10.105.54.134 is not valid for public use: in this case, 10.105.54.134 is the IP address of the "inside" of the proxy, only valid within your organization's network. The proxy must have another IP address that it uses for external traffic.

 

You may have to contact the administrator of the destination server, tell him/her the external IP address of your proxy, and ask him/her to check the server logs to find out what went wrong with the connection, and to add your proxy to the list of allowed hosts if necessary. (The SSH/SFTP server will not report connection error information to the client until the client has been authenticated; to do otherwise would leak information to potential intruders.)

MK
Abhzi
Advisor

Re: sftp routing through proxy server

Thanks MK for the detailed expalination on this issue. It really helped in getting broader vision about this issue.

 

As you said I have asked network team to perform the tests as you advised.

 

Meanwhile, I tried the sftp with by generating key at my server end and putting it in command using -oIdentityFile ...though it showed  ""OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008"" . Is this the open ssh version on files12.server.net?  As you were saying if the connection establishes, it shows open ssh version.

 

[abhzi@test1 ~]$ sftp -v -oIdentityFile=/home/swan/.ssh/swanid_rsa -oProxyCommand='/usr/bin/nc -v -X connect -x 10.105.54.134:8080 %h %p'  User@files12.server.net
Connecting to files12.server.net..
OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Executing proxy command: exec /usr/bin/nc -v -X connect -x 10.105.44.55:8080 files.swankmp.net 22
debug1: identity file /home/swan/.ssh/swanid_rsa type 1
debug1: loaded 1 keys
nc: Proxy error: "HTTP/1.1 200 Connection established"
ssh_exchange_identification: Connection closed by remote host
Couldn't read packet: Connection reset by peer
[abhzi@test1 ~]$

 

And this nc error, can this be issue with my current nc version on the server?

 

[abhzi@test1 ~]$ rpm -qa | grep -i nc
nc-1.84-10.fc6

ncurses-5.5-24.20060715
tunctl-1.5-3.el5
ncurses-5.5-24.20060715
ncurses-devel-5.5-24.20060715
ncurses-devel-5.5-24.20060

Matti_Kurkela
Honored Contributor
Solution

Re: sftp routing through proxy server

> ...though it showed  ""OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008"" . Is this the open ssh version on files12.server.net?

 

No, that's the OpenSSH version on your server. It is displayed when you use the -v option.

If the -v option is enabled, the remote version should be displayed like this:

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4

Without the -v option, the remote SSH version is not displayed. When testing a connection to a SSH server with a telnet client, the SSH version of the remote server gets displayed by the telnet client: this is a minor side effect of the SSH protocol. It helps when you are troubleshooting network issues: you can verify that a low-level connection to the SSH server works without even having a SSH/SFTP client available at all.

 

 > Meanwhile, I tried the sftp with by generating key at my server end and putting it in command using -oIdentityFile[...]

 

The problem is, your SFTP connection is getting closed before any kind of authentication can even start.

 

An identity file is only useful if public key authentication has been set up with the destination.

By default, the public key authentication of the client is not required - but the administrator of the remote server can configure the server to require it.

 

Normally, you would be able to set up public key authentication yourself, by first logging into the destination server using your password and then copying the public part of your authentication key (normally ~/.ssh/id_rsa.pub, if you use RSA keys, or ~/.ssh/id_dsa.pub if you use DSA keys) to ~/.ssh/authorized_keys on the destination server (assuming that the destination server is another OpenSSH server; if it is a commercial SSH product, the procedure at the destination host will be slightly different).

 

But if the destination server is configured to always require public key authentication, the only way to start using it would be to send the public part of the authentication key to the administrator of the destination server, who would then place it to the appropriate location.

 

> And this nc error, can this be issue with my current nc version on the server?

 

That is possible. It seems to be for a really old version (packaged for Fedora Core 6). Since Fedora Core 6 reached its end of life a long time ago, there are no longer any bug tracking resources for it. However, I found some bug reports for nc on Fedora 15, and here's one of them:

https://bugzilla.redhat.com/show_bug.cgi?id=846527

 

The "Additional information" part of the bug report says:

Additional info:
This nc program is really badly written. Although there is error handling there is no error output.  So when the bind() in unix_bind() fails then nobody gets told anything. There could be perror()'s just about everywhere a failure is detected but there are none.  One has to resort to strace to see what is going on.

 So if nc-1.100-2 still has problems with error reporting, I guess that your older version (nc-1.84-10.fc6) might be even worse.

 

The best way to troubleshoot an issue like this would be to get the relevant log entries from both the proxy server and the destination server: together, they should give you a reasonably complete picture about the problem.

MK