Sie sind immer wieder in den Nachrichten. Häufig leicht zu knacken und die Top 10 besteht sehr oft aus „123456“.

Gut, „immer wieder“ ist gerade überzogen, aber zumindest einmal jährlich werden von IT-Security-News-Outlets wie „Netzpiloten“ oder „t3n“ die meistgewählten Passwörter gekürt. Unter den erwarteten Beiträgen wie „123456“, „password“ oder „letmein“ spiegelt sich darin ein kleines Problem wider:
Der Sinn von Passwörtern wird oft nicht von den Nutzern wiedergegeben.

Passwörter sollen nicht nur eure Facebook-Accounts schützen, sondern auch euer System, euren Zugang zum Online-Banking und generell alles, was mit Geld zu tun hat, sollte unbedingt mit einem starken Passwort gesichert werden.

Was ist ein starkes Passwort?

Das Konzept „Passwort“ in sich ist zu unsicher.
Eigentlich sollte man gar aufhören, von „Passwörtern“ zu reden.


Once upon a time the Internet was bidirectional and everyone could run a server at their end. Unfortunately, these days are long gone and many ISPs today, especially cable providers, do not assign a public IPv4 address to their customers. Not even when you ask them nicely. Not even for money, unless you are a business customer who is willing to pay through the nose for the privilege. Fortunately, there is a way to run servers at home and make them accessible to the outside world and an easy one at that.

The program that makes this straight forward is ssh, or secure shell. Despite its name, ssh is the Swiss army knife when it comes establishing tunnels between different parts of the Internet through which TCP packets can be forwarded.

So making a server at home available despite a provider double NAT can be done by renting a server with a public IP address, preferably from a local cloud provider and then use it for forwarding packets. In my case, I pay €3 a month for such a server, that, by the way, I also use to run this blog on!

In the example, the server at home uses TCP port 7324 but should be accessible from the Internet on TCP port 8080. One would usually use the same ports but I thought an example with different ports is better to show if the local or the remote port is meant in my example below. In addition I use TCP port 39122 for ssh on the remote server instead of port 22 as my access log would otherwise be full with connection requests from bots on a mission.

Once things are working, autossh and crontab can be used to put the tunnel process into the background, to restore the tunnel automatically when it fails and to even survive reboots without administrative action. Have fun!