0

I'm running into an issue connecting from a Cygwin terminal to my home Raspberry Pi with SSH from behind an HTTP proxy. It used-to-work™ and I don't know what changed since a few days ago (maybe the proxy filtering?). I can still connect from outside the proxy-ed network without corkscrew.

Client-wise, my ssh-config is as follows:

Host *
        ServerAliveInterval 60
        ProxyCommand /bin/corkscrew http.proxy.here 80 %h %p

And the connection attempt gives this:

blx@proxyed-pc:~$ ssh blx@my.home.ip -v
OpenSSH_7.9p1, OpenSSL 1.0.2p  14 Aug 2018
debug1: Reading configuration data /home/blx/.ssh/config
debug1: /home/blx/.ssh/config line 1: Applying options for *
debug1: Executing proxy command: exec /bin/corkscrew http.proxy.here 80 my.home.ip 22
debug1: identity file /home/blx/.ssh/id_rsa type -1
debug1: identity file /home/blx/.ssh/id_rsa-cert type -1
debug1: identity file /home/blx/.ssh/id_dsa type -1
debug1: identity file /home/blx/.ssh/id_dsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ecdsa type 2
debug1: identity file /home/blx/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/blx/.ssh/id_ed25519 type -1
debug1: identity file /home/blx/.ssh/id_ed25519-cert type -1
debug1: identity file /home/blx/.ssh/id_xmss type -1
debug1: identity file /home/blx/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: Connection closed by remote host

Server-wise, /var/log/auth reports this:

Nov 26 13: 39:36 raspi sshd[19130]: debug1: Forked child 19699.
Nov 26 13: 39:36 raspi sshd[19699]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:36 raspi sshd[19699]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:36 raspi sshd[19699]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:36 raspi sshd[19699]: debug1: getpeername failed: Transport endpoint is not connected
Nov 26 13: 39:36 raspi sshd[19699]: debug1: ssh_remote_port failed

So the TCP connection seems broken, but I don't seem to have this issue when I try to connect with corkscrew directly (i.e. $corkscrew http.proxy.here 80 my.home.ip 22):

Nov 26 13: 39:32 raspi sshd[19130]: debug1: Forked child 19698.
Nov 26 13: 39:32 raspi sshd[19698]: debug1: Set /proc/self/oom_score_adj to 0
Nov 26 13: 39:32 raspi sshd[19698]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Nov 26 13: 39:32 raspi sshd[19698]: debug1: inetd sockets after dupping: 3, 3
Nov 26 13: 39:32 raspi sshd[19698]: Connection from http.proxy.here port 28220 on 192.168.0.11 port 22
Nov 26 13: 39:32 raspi sshd[19698]: Did not receive identification string from http.proxy.here port 28220

But then of course sshd doesn't know what to do of this...

Any tip? Since I don't think I changed anything in my setup I suspect a sneaky update of the proxy filtering policy that puts me in this situation, but I have no way to be sure. I will try and update my router and Pi to use port 443 when I get home.

0

we need to agree that there is no intent of bypassing some security measures and that connecting this way is in no breach of any contract / agreement, of course. Pseudo-legal disclaimer done, if I were you I'd indeed try to switch my server to listen for SSH connections on port 443 better than any other, if going through a web proxy. Simple reasons:

  • While communications on port 80 (normal web traffic) are unencrypted and mostly plain text (when reading a page), port 443 is for SSL cyphered communications. A proxy won't be surprised to see communications in binary form through that port. You need a binary connection for SSH, not like a web page.
  • You're not exposing your server to the public (if you don't have a ip white list firewall on the other side) with a commonly known port like 22. A new server online lasts unprobed sometimes even less than 5 minutes. Then somebody from somewhere is going to try to login via SSH, if they see the port 22 open. Port 443 doesn't add much more security but at least it's a little less obvious than 22. Good luck!
  • No breach of contract intended, no worries! After further attempts I came to the conclusion that the proxy has a new Deep Packet Inspection feature. I tried to establish an SSL tunnel on port 443 using stunnel on the server and proxytunnel on the client, but even then I clearly see the connection being dropped as soon as SSH data goes through. The proxy acts as a MitM thanks to its self-signed certificate installed on the client. I prefer to give up at this point, but thanks for you input! – blx Dec 4 '18 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.