I don't manage my hobby, I need to use an email client

If you're replying to my post, note that I did not mention anything about ports, but instead the listening address. Unless the OP's Linode starts spamming his employer's network, I doubt they'll block his Linode's IP address.

Hence my suggestion to not use a listening address still stand, although this suggestions is entirely safe to ignore

_________________
Kris the Piki Geeker

it seems that you know what ListenAddress is, what is this parameter exactly ?

It's to tell sshd what IP addresses to listen for connections on.

For instance, if you decide to set up your Linode as a shared host, you could purchase a separate IP address for each individual customer. If you don't want those customers to have ssh access, you could have one additional IP address just for yourself (one your customers aren't allowed to use) and make sshd listen only on that reserved address.

This is just an example, there's nothing really stopping those customers from attempting to ssh to your reserved address (or using it for a domain). ListenAddress is probably best used on an internal network, however reasons for using it will vary.

_________________
Kris the Piki Geeker

You could bind ssh to port 443 on you IP6 address and hope the corporate network passes IP6 traffic.
Purchase a 2nd IP4 address and bind ssh to port 443 on that new IP address.

Even if you go down this path, and your corporate network admins are worth their salt, they'll be doing some form of content inspection that will tell them your ssh traffic on port 443 just isn't https traffic, and they'll kill it anyway.

they inspect traffic, they have some other ports opened, they kill connection if they don't see https traffic.
443 is opened without any control and I solved using the multiplexer on that port.

I finded a huge problem on this approach.
SSLH is a multiplexer that redirect all the incoming traffic 443 to the correct port.

The huge problem in this approach is that all people who access my HTTPS site is redirected to 8443 (the port where SSL is listening) but with the 127.0.0.1 address.

My logs are full of different people using the HTTPS service but the only IP Address I find in log now is 127.0.0.1

This is clear because people connect to HTTPS standard port (443) the multiplexer redirect from localhost to the 8443.

In this way logs means nothing, I cannot trace any IP address and this is not good al all, fail2ban
obviously stopped working too.

Is there a possible solution to this problem?
Any idea?

Use a network connection that doesn't block port 22?

_________________

/* TODO: need to add signature to posts */

come on, be serious! it's never that easy

Normal web reverse proxies like HAProxy and nginx have capability of passing along real IP address in HTTP headers.

sslh does it a little differently though. From the README:

==== Transparent proxy support ====

On Linux (only?) you can use the --transparent option to
request transparent proying. This means services behind sslh
(Apache, sshd and so on) will see the external IP and ports
as if the external world connected directly to them. This
simplifies IP-based access control (or makes it possible at
all).

sslh needs extended rights to perform this: you'll need to
give it cap_net_admin capabilities (see appropriate chapter)
or run it as root (but don't do that).

The firewalling tables also need to be adjusted as follow
(example to connect to https on 4443 -- adapt to your needs
(I don't think it is possible to have httpd listen to 443 in
this scheme -- let me know if you manage that))):

# iptables -t mangle -N SSLH
# iptables -t mangle -A  OUTPUT --protocol tcp --out-interface eth0 --sport 22 --jump SSLH
# iptables -t mangle -A OUTPUT --protocol tcp --out-interface eth0 --sport 4443 --jump SSLH
# iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
# iptables -t mangle -A SSLH --jump ACCEPT
# ip rule add fwmark 0x1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100

This will only work if sslh does not use any loopback
addresses (no 127.0.0.1 or localhost), you'll need to use
explicit IP addresses (or names):

sslh --listen 192.168.0.1:443 --ssh 192.168.0.1:22 --ssl 192.168.0.1:4443

This will not work:
sslh --listen 192.168.0.1:443 --ssh 127.0.0.1:22 --ssl 127.0.0.1:4443

Thanks for the reply!!!
I'm reading the readme too but I don't understood how to enable this "transparent mode"...

have you understood it?

I'm starting the sslh with --transparent option but when I go to an https site I get this error:
setsockopt: Operation not permitted

if I remove the --transparent it works like a charm.

I alsa done
setcap cap_net_bind_service,cap_net_admin+pe sslh
for a try
but same problem.

any idea?

Can you try running it as root and see if it works?

If it works as root that means the sslh README was probably incomplete and you need more permissions than cap_net_admin.

If I set

in /etc/ssh/sshd_config

and I run it as root with this settings in the /etc/rc.d/init.d/sslh


It works like a charm, but in this way it is using root

I must be a problem of permission because it says:
setsockopt: Operation not permitted

if I run as a normal user.
no problem by root.