Can't tunnel SSH

[dimzon]

Server:

fteproxy --mode server --server_ip 0.0.0.0  --proxy_port 22 &

Client:

fteproxy --mode client --server_ip x.x.x.x &

SSH Invocation

me@nas:~$ ssh -24 -k -v 127.0.0.1 -p 8079 
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 127.0.0.1 [127.0.0.1] port 8079.
debug1: Connection established.
debug1: identity file /home/me/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/me/.ssh/id_rsa-cert type -1
debug1: identity file /home/me/.ssh/id_dsa type -1
debug1: identity file /home/me/.ssh/id_dsa-cert type -1
debug1: identity file /home/me/.ssh/id_ecdsa type -1
debug1: identity file /home/me/.ssh/id_ecdsa-cert type -1
ssh_exchange_identification: Connection closed by remote host

obfsproxy works fine (obfs2 obfs3 b64)

[kpdyer]

Thanks dimzon for the report. However, I'm unfortunately unable to reproduce this problem.

• Are you able to recreate this issue with the client/server on the same machine?
• What OS are you on?

Finally, for my sanity, can you confirm that a direct ssh connection to the server works?

-Kevin

[dimzon]

My OS: server

root@vpn:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.04.2 LTS
Release:    14.04
Codename:   trusty
root@vpn:~# uname -a
Linux vpn 2.6.32-042stab103.6 #1 SMP Wed Jan 21 13:07:39 MSK 2015 i686 i686 i686 GNU/Linux

client1:

root@nano128:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 7.8 (wheezy)
Release:    7.8
Codename:   wheezy
root@nano128:~# uname -a
Linux nano128 2.6.32-042stab102.9 #1 SMP Fri Dec 19 20:34:40 MSK 2014 i686 GNU/Linux

client2:

me@nas:/etc/ssh$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 12.04.2 LTS
Release:    12.04
Codename:   precise
me@nas:/etc/ssh$ uname -a
Linux nas 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux

No, client/server on same machine works fine. Direct ssh connection to the server works fine. Connection via obfsproxy (using all methods and via same TCP ports as fteproxy) works fine

also SSHD log from server:

root@vpn:~# cat /var/log/auth.log | tail -6
Mar 17 00:14:33 vpn sshd[379]: debug1: Forked child 536.
Mar 17 00:14:33 vpn sshd[536]: Set /proc/self/oom_score_adj to -800
Mar 17 00:14:33 vpn sshd[536]: debug1: rexec start in 11 out 11 newsock 11 pipe 13 sock 14
Mar 17 00:14:33 vpn sshd[536]: debug1: inetd sockets after dupping: 3, 3
Mar 17 00:14:33 vpn sshd[536]: Connection from 127.0.0.1 port 46993 on 127.0.0.1 port 22
Mar 17 00:14:33 vpn sshd[536]: Did not receive identification string from 127.0.0.1

[dimzon]

PS. If you still can't reproduce - I can provide you my VPS for testing, just drop me your id_rsa public key

[kpdyer]

Have you tried running client/server on the same machine on both the SSH client and SSH server?

What version of fteproxy are you running?

[dimzon]

I'm using such script:

killall fteproxy
killall obfsproxy
sleep 10s
fteproxy --mode server --server_ip 0.0.0.0  --proxy_port 22 > /dev/null &
fteproxy --mode client --server_ip 127.0.0.1 > /dev/null &
sleep 5s
ssh 127.0.0.1 -p 8079

I'm confused a shot - this works on "server" (see above) only! Both "clients" breaks with same error...

on all 3 machines version is same

me@nas:~$ pip search fteproxy
fteproxy                  - fteproxy
  INSTALLED: 0.2.19 (latest)

[kpdyer]

Is SSH running on the machines on the machines where it fails? (i.e., does "ssh 127.0.0.1" work?)

[kpdyer]

Also, could it be a firewall issue? Are ports 8079, 8080 and 22 accessible via TCP?

[dimzon]

Is SSH running on the machines on the machines where it fails? (i.e., does "ssh 127.0.0.1" work?)

yes

Also, could it be a firewall issue? Are ports 8079, 8080 and 22 accessible via TCP?

AFAIK there are no FW for loopback (127.0.0.1)

PS. there are no problems accessing those VPS directly by SSH - I'm just training/preparing to bypass upcoming russian censorship

[kpdyer]

Two final questions:

1. You see this problem from both clients, right?
2. What if you turn one of the clients into the server. Do you experience the same problem?

[dimzon]

1. Yes. And Client2 also have same problem for obfs proxy too :(
2. Uh, that's final test:

server:22->server:8080 (--server) ->server:8079 (--client) - works
client1:22->client1:8080 (--server) ->client1:8079 (--client) -not work
client2:22->client2:8080 (--server) ->client2:8079 (--client) -not work

server:22->server:12010 (--server) ->client1:8079 (--client) - not work
server:22->server:12010 (--server) ->client2:8079 (--client) - not work

client1:22->client1:12010 (--server) ->server:8079 (--client) - works (client 1 behind nat, port-rage 12001-12020 accessible)
client2:22->client2:12010 (--server) ->server:8079 (--client) - unapplicable (client2 behind nat, no free accessible ports)

every time I have same ssh messages. according SSH server-side log at least something from client reach server endpoint:

Mar 17 00:14:33 vpn sshd[536]: Connection from 127.0.0.1 port 46993 on 127.0.0.1 port 22
Mar 17 00:14:33 vpn sshd[536]: Did not receive identification string from 127.0.0.1

[dimzon]

And yes, i compared ssh / sshd settings on all nodes - they are same! I checked hosts.allow/hosts/deny - same! fail2ban not installed on any node

[kpdyer]

I'm now able to recreate this issue.

I'll need to dig a bit deeper to determine if this is an fteproxy issue, or an SSH configuration issue.

[dimzon]

Other non python tunnels works perfectly in all variations 17.03.2015 18:55 ÐÏÌØÚÏ×ÁÔÅÌØ "Kevin P. Dyer" notifications@github.com ÎÁÐÉÓÁÌ:

I'm now able to recreate this issue.

I'll need to dig a bit deeper to determine if this is an fteproxy issue, or an SSH configuration issue.

Reply to this email directly or view it on GitHub https://github.com/kpdyer/fteproxy/issues/172#issuecomment-82432784.

[dimzon]

Client2 also has same issue with obfsproxy so take look at common code if any 17.03.2015 18:55 ÐÏÌØÚÏ×ÁÔÅÌØ "Kevin P. Dyer" notifications@github.com ÎÁÐÉÓÁÌ:

I'm now able to recreate this issue.

I'll need to dig a bit deeper to determine if this is an fteproxy issue, or an SSH configuration issue.

Reply to this email directly or view it on GitHub https://github.com/kpdyer/fteproxy/issues/172#issuecomment-82432784.

[dimzon]

any progress?

[kpdyer]

Unfortunately not. This fell to the bottom of my queue, and I probably won't be able to get to it until next week.

[irdan]

@dimzon @kpdyer

Using the latest master branch I cannot reproduce this issue. If this is still reproducible please provide the set of steps taken on both the client and server to reproduce.

[kpdyer]

Very interesting. Did you do this test on the same machine, or separate?

@dimzon - Is the issue fixed for you?

[irdan]

I tested it on two different machines. First I verified it worked within each machine, then I tried it between the two and it worked.