Windows 10 port forwarding 445

The minimum needed to access Windows or Samba shares over a network is port 139 TCP - I've used this to tunnel Samba connections through SSH connections a number of times.

SMB is not an encrypted protocol as you have already found, so I strongly recommend against opening it to the outside world directly instead of allowing users to connect via a secure tunnel such as that provided by SSH or some form of more general VPN. I believe that the authentication method used is safe to perform in the plain (it is a challenge response arrangement that doesn't require plain text credentials to be transferred) so if you can guarantee that content on the shares is not sensitive you can get away with not using a tunnel/VPN but I would still recommend it as an additional level of security if only so that you can control who has access remotely separately from those who have access at all. Also a SSH tunnel or VPN can support compression which will reduce bandwidth requirements when the shares are accessed remotely.

There have been no successful unauthenticated remote attacks reported against Samba in my recent memory, so you are probably safe from that point of view, though again I'd suggest tunnelling the protocol instead of opening it plain. Having port 139 and others open will be an invitation to try if any remotely exploitable issues are found.

Another serious issue will be user password security. If the service is open and a user has an insecure password (either not complex enough, or something guessable by a cracker, and so on) then you have a serious problem. So you need to make sure you have a good password policy in place. Using a VPN like OpenVPN will mitigate this somewhat as people will need to have a keyset for the VPN too, though you can't guarantee that a user will keep their private key safe either...

I agree with MadHatter, that it is likely to be port forwardings from defunct ssh connections. Even if your current problem turns out to be something else, you can expect to run into such defunct ssh connections sooner or later.

There are three ways such defunct connections can happen:

• One of the two endpoints got rebooted while the other end of the connection was completely idle.
• One of the two endpoints closed the connection, but at the time where the connection was closed, there was a temporary outage on the connection. The outage lasted for a few minutes after the connection was closed, and thus the other end never learned about the closed connection.
• The connection is still completely functional at both endpoints of the ssh connection, but somebody has put a stateful device somewhere between them, which timed out the connection due to idleness. This stateful device would be either a NAT or a firewall, the firewall you already mentioned is a prime suspect.

Figuring out which of the above three is happening is not highly important, because there is a method, which will address all three. That is the use of keepalive messages.

You should look into the ClientAliveInterval keyword for sshd_config and the ServerAliveInterval interval for ssh_config or ~/.ssh/config.

Running the ssh command in a loop can work fine. It is a good idea to insert a sleep in the loop as well such that you don't end up flooding the server when the connection for some reason fails.

If the client reconnect before the connection has terminated on the server, you can end up in a situation where the new ssh connection is live, but has no port forwardings. In order to avoid that, you need to use the ExitOnForwardFailure keyword on the client side.