# [SOLVD] problem with SSL on port 443 and broken SSL packet?

## shimitar

Ok, i am completely unable to do any further step here. Maybe somebody can help.

I have updated an AMD64 server last weekend and it broke something.

This is the situation: 

the server has SSH over port 443 (to bypass a proxy)

This is the problem:

It is not possible to connect to my SSH on port 443 using Linux (tryed gentoo, gentoo sparc and kubuntu), but it is possible to connect using windows XP.

For example:

ssh myserver -p 443 (or putty from linux)

will result in a connection refused.

but putty from windows will connect fine on port 443.

Doing some analysis with wireshark the proble its pretty clear: the server RESET (RST) the TCP stream right after receiving the OpenSSH header from the client due to a broken SSL data stream!

Now i am puzzled. This used to work until last friday morning. I can provide wireshark dumps any more details, just ask what so i do not overload this thread. 

Does anybody have some insights to help me?

----------

## DawgG

don't worry, this is expected behavior (of the proxy.)

when you use putty on windoze, the program has built-in proxy-"support", meaning it can get the proxy to allow a connection from your client -> your server using the http-connect-method which is allowed on most proxies for ssl (standard port 443) which cannot be proxied (end-to-end-encryption between client and server). this is an additional function provided by putty which has nothing to do with ssh.

when you just start your ssh client-program as described, it will probably use the proxy (provided by environment var) which will just try to establish an ssl-connection to your sshd:443 (which of course cannot work).

maybe something was changed on the proxy? are you certain the RST comes from your server and not from the proxy? can you post the output of 

```
ssh -vv myserver
```

was sshd's config changed?

----------

## shimitar

Ok, this is ssh -vv server output:

(all the following examples are from direct ssh, exactly the same happens with the proxy in the loop, which i will add after i solved this problem)

```

willy@kubuntu:~$ ssh aaa.bbb.ccc.ddd -p 443 -vvv

OpenSSH_5.1p1 Debian-5ubuntu1, OpenSSL 0.9.8g 19 Oct 2007

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug2: ssh_connect: needpriv 0

debug1: Connecting to aaa.bbb.ccc.ddd [aaa.bbb.ccc.ddd] port 443.

debug1: Connection established.

debug1: identity file /home/willy/.ssh/identity type -1

debug1: identity file /home/willy/.ssh/id_rsa type -1

debug1: identity file /home/willy/.ssh/id_dsa type -1

ssh_exchange_identification: read: Connection reset by peer

willy@kubuntu:~$

```

SSHD config might have been changed, but i double checked it and nothing seems to be wrong.

This is the output from the server side when i run it in foreground and debug mode:

```

debug1: Bind to port 443 on aaa.bbb.ccc.ddd.

Server listening on aaa.bbb.ccc.ddd port 443.

debug3: fd 7 is not O_NONBLOCK

debug1: Server will not fork when running in debugging mode.

debug3: send_rexec_state: entering fd = 10 config len 375

debug3: ssh_msg_send: type 0

debug3: send_rexec_state: done

debug1: rexec start in 7 out 7 newsock 7 pipe -1 sock 10

debug1: inetd sockets after dupping: 3, 3

Connection from 151.81.7.60 port 48364

Did not receive identification string from 151.81.7.60

```

Then it returns to the prompt.

I can post the wireshark dump if you think it is relevant, you can see the RST (on the server side) and on the client side (ehre you can see the FIN ACK sequence)

----------

## DawgG

i can't look into it rite now, but i'm certain the  *Quote:*   

> Did not receive identification string from 151.81.7.60 

  from sshd is an indicator that it has received non-ssh-traffic, it can happen when you eg do a portscan or telnet to a port sshd listens on.

----------

## ScarletPimpFromHell

My first thought would be a incompatable list of authentication ciphers/hash options between client and server. You could try enabling verbose debugging of the server for more information.

Edit: Just had another thought. When you updated the openSSL libraries and recompiled sshd did the server certificates get regenerated ? You may have to flush the cached fingerprints on your client as well.

----------

## shimitar

Actually, i solved the problem.

The problem was the most obvious one, thats why i did not thought of it: the "other end" (the remote end) has changed the perimetral firewall policy to kill any non-SSL connection on port 443.

The BIG puzzling question is why it works using PUTTY under Windows and does not work using PUTTY (same version!) under linux?

----------

