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 [email protected] -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.

1 Answer 1

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!
1
  • 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, 2018 at 16:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .