Last time we covered a very basic setup. Multiple people have contacted me so far requesting an explanation on how to move towards a slightly more sophisticated authentication setup. Usually involving a php script to authenticate against. Maybe you want to use an existing mySQL or mariaDB database to set up users and channels? Fear not, this is not that complicated to start out with.

Server side configuration

Starting from this example, we set up a basic rtmp section:

rtmp {
  server {
    listen 1935;
	ping 30s;
	notify_method get;
	application stream {
	  live on;
	  record off;


Most people who stream enjoy using services such as or Ustream to deliver video to viewers, and that works well enough. But sometimes you want some more control over your stream, or you want other people to be able to stream to you, or you want to stream to multiple places, or any number of things that requires you to have access to an actual RTMP stream from an RTMP server. This guide will cover the very basics of setting up a simple RTMP server on a Linux computer. Don’t worry, it’s not too complicated, but having familiarity with Linux will certainly help.

A couple things you can do with your own RTMP server that you might be interested in:

Alright, so how do you do these kinds of things?


Wenn man in der Datei ~alice/.ssh/authorized_keys den mit ssh_keygen erzeugten Public-Key des Users bob einfügt und bob ist in der Gruppe, zu der die Datei ~alice/.ssh/authorized_keys gehört (typischerweise auch alice), dann darf die Datei ~alice/.ssh/authorized_keys keine Gruppen-Schreibrechte haben, sonst kann sich bob nicht passwortlos als alice anmelden. Das ergibt Sinn, man muss aber erst einmal drauf kommen. Am Besten setzt man die Rechte der authorized_keys-Dateien eh auf 600 (chmod 600 ~/.ssh/authorized_keys oder chmod go-rwx ~/.ssh/authorized_keys).

Wofür man solches wissen muss? Angenommen, einer Gruppe von Usern soll erlaubt werden, ein ganz konkretes Programm auch als User alice und nicht nur in der Gruppe alice ausführen zu dürfen, dann lässt sich dafür das viel (und oft aus falschen Gründen) gescholtene sudo nutzen, indem in /etc/sudoers mittels sudo visudo

%alice ALL=(alice) NOPASSWD:/home/alice/bin/

eingetragen wird. Damit wird dafür gesorgt, dass Mitglieder der Gruppe alice (%alice) das Programm ~alice/bin/ mit

sudo -u alice /home/alice/bin/

ausführen dürfen. Dabei muss natürlich darauf geachtet werden, dass in keine Sicherheitslöcher beispielsweise durch less entstehen. (! in less ermöglicht beliebige Shell-Kommandos – dann als User alice).


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!