Mailcow – Der Mailserver mit dem ‘moo’

Genau genommen ist Mailcow eine “mailserver suite” und nicht nur ein normaler Mailserver. Mailcow basiert auf vielen Einzeltools, die bei einem heutigen Mailserver “State of the art” sind, aber schön und simpel verpackt. Dadurch ist es möglich, schnell und unkompliziert einen adäquaten Mailserver zu betreiben, ohne sich vorher tagelang mit den einzelnen Tools auseinandersetzen oder How-tos googeln zu müssen.

 

Die Mailcow besteht unter anderem aus:

  • Postfix – Mail Transfer Agent
  • Dovecot – Mail Delivery Agent
  • MariaDB – zur Haltung verschiedenster Daten und Einstellungen
  • PHP – klar, braucht man irgendwie immer 😉
  • Nginx – Webserver
  • Unbound – DNS resolver
  • SOGo – Groupware
  • Rspamd – SPAM Filter
  • ClamAV – AntiVirus

Aus diesen Tools zaubert die Mailcow einen Funktionsumfang, der sich sehen lassen kann.

Die Highlights:

  • Hosting mehrerer Domains und Postfächer und Aliase
  • Wildcard-Postfächer (z. B. *@mydomain.com als Umleitung auf sammelpostfach@mydomain.com)
  • Rate Limits pro User und/oder Domain (z. B. Messages pro Sekunde / Minuten / Stunde)
  • Black- und Whitelisting von Domains und/oder E-Mail-Adressen
  • DKIM und ARC Support
  • SPAM Score Management (Reject, als SPAM markieren, Graylisting)
  • Zweifaktor-Auth (z. B. Yubikey OTP, U2F USB, TOTP)
  • AntiVirus

Aus Erfahrung kann ich sagen, dass die Updates reibungslos laufen und durch die Admin-GUI sehr viel und einfach konfiguriert werden kann. Die SOGo Groupware verrichtet problemlos ihren Dienst für mehrere (auch unbedarfte) Nutzer und bei SPAM lassen sich dank der Rspamd GUI endlich vernünftige Rückschlüsse auf das Innere des SPAM-Filters werfen.

Solltet ihr auf den Geschmack gekommen sein, kann ich euch die Mailcow wärmstens empfehlen. Die dazugehörige Docker-Repo findet ihr unter https://github.com/mailcow/mailcow-dockerized. Die Dokumentation liegt unter https://mailcow.github.io/mailcow-dockerized-docs.

Tobias Redel
Tobias Redel
Head of Professional Services

Tobias hat nach seiner Ausbildung als Fachinformatiker bei der Deutschen Telekom bei T-Systems gearbeitet. Seit August 2008 ist er bei NETWAYS, wo er in der Consulting-Truppe unsere Kunden in Sachen Open Source, Monitoring und Systems Management unterstützt. Insgeheim führt er jedoch ein Doppelleben als Travel-Hacker, arbeitet an seiner dritten Millionen Euro (aus den ersten beiden ist nix geworden) und versucht die Weltherrschaft an sich zu reißen.
Sollte man beim Weihnachtsfest über Politik sprechen?

Sollte man beim Weihnachtsfest über Politik sprechen?

TLTR – Ja absolut, wann denn sonst?!

Zugegeben hoffe ich sehr, dass ihr euch trotz Weihnachtsvorbereitungen und dem damit verbundenen Stress etwas mehr Zeit zum Lesen nehmt, denn die gegebene Antwort ist natürlich durchaus streitbar. Darüber hinaus ist mir auch völlig bewusst, dass wir in erster Linie ein Technologieunternehmen sind und der Leser nicht wegen unserer bzw. meiner politischen Meinung hier ist. Aber wir haben ein Medium, mit dem wir Kunden, Lieferanten und all diejenigen erreichen können, mit denen wir zusammenarbeiten. Nicht weniger wichtig aber auch ein Medium, mit dem wir uns noch unbekannte Menschen erreichen können und daher hat es für mich durchaus auch einen Platz hier verdient.

Politik und Unternehmen

Was mich derzeit besorgt, ist der zunehmende Trend, Politik und politische Ansichten aus Unternehmen verbannen zu wollen. Gerade in den USA bekamen in den letzten Monaten viele Technologieunternehmen die Macht der Community zu spüren, welche sich sehr deutlich gegen eine staatliche Zusammenarbeit mit der “Immigration and Customs Enforcement” (kurz ICE) aussprach. Diese Bundesbehörde zeichnet u.a. für die teils menschenunwürdige Trennung von Kindern und deren Eltern verantwortlich und ist gerade deshalb im Fokus der Öffentlichkeit. Der öffentliche Druck hatte nicht zuletzt die weitere Zusammenarbeit zwischen ICE und Chef beendet und das Unternehmen zum Einlenken gezwungen.

Drang zur Neutralität

Auch wenn ich keinen direkten Zusammenhang herstellen kann, hat GitLab nur drei Tage darauf seine öffentlichen Richtlinien zur “Customer Acceptance” geändert und aufgrund heftiger Reaktionen einige Tage später wieder entschärft. Dabei ist es mit Sicherheit nicht das einzige Technologieunternehmen und auch GitHub und Google ringen mit der eigenen Position, aber aufgrund der offenen Meinungsfindung ist die Diskussion bei GitLab sehr transparent und dient daher als Beispiel. Im Ergebnis führt es dazu, dass Unternehmen möglichst wenig Positionierung ihrer Mitarbeiter wünschen und dies in internen Regelungen so deutlich formulieren, dass es teils schon staatliche Behörden auf den Plan gerufen hat, die diese Unternehmen an das Recht zur freien Meinungsäußerung erinnert haben. Vor nun fast zwei Jahren habe ich mein damaliges Verständnis von politischer Meinung und Verantwortung der Unternehmen hier Blog zusammengefasst. Die Zustimmungswerte der AfD fand ich schon damals sehr besorgniserregend und muss heute leider sagen, dass es nicht “besser” geworden ist. Jetzt mag nicht jeder gleich die Brücke zum amerikanischen Wertesystem schließen, aber ich habe den Eindruck, dass wir uns als Gesellschaft auf selbiges zubewegen. Auch in unserer Politik geht es immer weniger um wirkliche Sachfragen, sondern um politische Polarisierung und Instrumentalisierung.

Unsere Verantwortung

In einer Zeit des politischen Umbruchs liegt es umso mehr an jedem einzelnen von uns, für seine Überzeugungen einzutreten und diese auch kundzutun. Da gehört es selbstverständlich auch dazu, dass wir nicht immer der gleichen Meinung sind. Das Vertreten einer Meinung, deren Akzeptanz, aber auch der Widerspruch gehören zu unserer Gesellschaft, zu unserem Wertesystem und auch zu unserem Unternehmen. Wenn sich Unternehmen mehr und mehr deshalb von politischer Meinung distanzieren, da sie befürchten, Kunden zu verlieren, ist das aus meiner Sicht fatal. Vielleicht nicht sofort für das Unternehmen, aber mittel- und langfristig für unsere Gesellschaft.

Was hat das jetzt mit dem Weihnachtsfest zu tun?

Am vergangenen Freitag hatten wir unser NETWAYS Weihnachtsfest und meine Lieben haben das Buch “Selbstbetrachtungen” von Mark Aurel geschenkt bekommen. Der römische Kaiser und Philosoph prägte u.a. auch nachfolgendes Zitat:

“Oft tut auch der Unrecht, der nichts tut. Wer das Unrecht nicht verbietet, wenn er kann, der befiehlt es.”

Viele von uns haben doch diesen Opa, Onkel, Schwager oder ähnlichen Verwandten, der irgendwann im Laufe des Abends mit einer oft anstößigen, verzerrten und manchmal auch beleidigenden Aussage glänzt. Ob nun gegen Ausländer, die Greta, Dieselfahrverbot oder Windräder. Eigentlich ist es vollkommen egal, aber ein anderer Teil am Tisch denkt sich sofort:

“Ich sag besser nix, da gibt es nur Streiterei.”

Wenn euch der Gedanke kommt, und dazu möchte ich euch ermutigen, ist es das Richtige das Gegenteil zu tun. Wir brauchen mehr Diskussionen und Meinungsaustausch und vielleicht manchmal auch Streit. Ich will euch ja beim besten Willen nicht das Weihnachtsfest versauen, aber wenn wir es schon daheim nicht machen und dort auch mit unserer Meinung hinterm Zaun halten, wo bitte denn dann?

In diesem Sinne wünsche ich euch auch im Namen aller bei NETWAYS ein schönes Weihnachtsfest. Wenn ihr kein Weihnachten feiert, wünsche ich Euch ein paar Tage Ruhe und das bessere Gefühl, danach nicht vollgefressen auf der Couch zu liegen.

Den Menschen, für die Weihnachten eine schwere Zeit ist, wünsche ich Kraft und auch den Mut, Hilfe in Anspruch zu nehmen.

Alles Gute für euch!

Bernd Erk
Bernd Erk
CEO

Bernd ist Geschäftsführer der NETWAYS Gruppe und verantwortet die Strategie und das Tagesgeschäft. Bei NETWAYS kümmert er sich eigentlich um alles, was andere nicht machen wollen oder können (meistens eher wollen). Darüber hinaus startet er das wöchentliche Lexware-Backup und investiert seine ganze Energie in den Rest der Truppe und versucht für kollektives Glück zu sorgen. In seiner Freizeit macht er mit sinnlosen Ideen seine Frau verrückt und verbündet sich dafür mit seinem Sohn.

Was ist Consul und wozu dient es?

Eine Beschreibung in einem Wort ist hier Service Mesh. Was jemanden, der sich zuerst mit Consul beschäftigt, ebenfalls nicht wirklich weiterhilft. Dieser Blogpost zeigt die Features von Consul auf und gibt Hinweise zu deren Anwendung.

Consul verwaltet Services und Knoten in der Art eines “Verzeichnisdienstes”, also in der Form was läuft wo? Zugegriffen wird dabei über DNS oder alternativ mittels HTTP(s). Consul wird entweder im Modus Server oder Agent betrieben. Die Server speichern die Daten, kommen mehrere zum Einsatz werden die Daten automatisch synchronisiert.

Auf die Daten kann man direkt auf den Servern mittels DNS oder HTTP(s) zugreifen oder über den eh benötigten Agenten. Über den Agenten meldet sich jeder beliebige Knoten bzw. Host in Consul an und wird als Node registriert. Ebenfalls können dann auch Services registriert werden. Ein Webserver z.B. registriert sich so zum Beispiel als neues Cluster-Mitglied zu einem bereits bestehenden Services. Zusätzlich können auch Tags gesetzt werden, die sich via DNS-Abfrage dann als Aliases darstellen.

Nur was macht man nun mit diesen Informationen? Einfach wäre es nun seinen eigentlichen DNS auf diese Informationen weiterzuleiten. Dies geht wie oben schon angedeutet mit Anfragen entweder direkt an die Server oder über einen auf den DNS-Servern betriebenen Agenten. Damit ist leicht ein DNS-Round-Robin zu realisieren.

Möchte man hingegen einen Load-Balancer als Proxy für seinen Dienst betreiben, kommt Consul-Templates als eigenständiges Produkt ins Spiel. Es handelt sich hierbei um eine Template-Engine, die die Informationen aus Consul in Konfigurationsdateien überführt. Die Konfiguration kann dabei noch um zusätzliche Konfigurationsparamter, aus dem in Consul integrierten Key-Value-Store, angereichert werden.

Abschließend bietet Consul als weiteres Feature die Verwaltung einer Certificate Authority (CA). Die ausgestellten Zertifikate können sogleich mit Hilfe des Agents via Proxy (sidecar proxy) zur Absicherung der betriebenen Dienste mittels TLS eingesetzt werden. Das geschieht völlig transparent und Konfigurationsdateien müssen nicht angepasst werden.

Lennart Betz
Lennart Betz
Senior Consultant

Der diplomierte Mathematiker arbeitet bei NETWAYS im Bereich Consulting und bereichert seine Kunden mit seinem Wissen zu Icinga, Nagios und anderen Open Source Administrationstools. Im Büro erleuchtet Lennart seine Kollegen mit fundierten geschichtlichen Vorträgen die seinesgleichen suchen.
A journey with Vault – Teil 1

A journey with Vault – Teil 1

This entry is part of 1 in the series a journey with vault

Hello fellow blog readers!

Heute möchte ich euch auf die Reise mit Vault by Hashicorp mitnehmen.

Zunächst was ist Vault? Bei Vault handelt es sich stumpf gesagt, um einen Passwortspeicher. Vermutlich kommen da jetzt bei dem einen oder anderen Projekte wie Keypass oder Enpass in den Sinn. Die Richtung ist schon mal gut. Jedoch kennt auch jeder das Hauptproblem der oben genannten Lösungen nur zu gut.

Teamfähigkeit.

Das eine Projekt beherrscht es, andere nur teilweise oder vieleicht sogar garnicht. Frustrierend könnte man die Situation auch gerne umschreiben. Fakt ist auf jeden Fall das es sich bei Vault um eine Lösung handelt, die wirklich das Zeug dazu hat ein Teamfähiger Passwortspeicher zu sein. Wie so alles in der Welt haben Dinge leider ihren Preis. Man wird mit Teamfähigkeit gesegnet, aber Satan bestraft uns indirekt mit der Komplexität des ganzen Konstrukts, weswegen ich das Abenteuer Vault in eine kleine Serie verpacke. Genug Worte für den Einstieg, legen wir los mit dem neuen Abenteuer in der Hautprolle: Vault.

Part Uno widment sich der grundlegenden Inbetriebnahme von Vault.

Wie immer benutzte ich eine mit Vagrant provisionierte höchst aktuelle CentOS 7 Box der Marke Eigenbau mit VirtualBox als Provider.

Die Reise beginnt mit dem Download eines ZIP-Archivs welche das Vault binary enthält. Den legen wir einfach unter /tmp ab und entpacken ihn direkt nach /usr/local/bin

wget https://releases.hashicorp.com/vault/1.3.0/vault_1.3.0_linux_amd64.zip -P /tmp
unzip /tmp/vault_1.3.0_linux_amd64.zip -d /usr/local/bin
chown root. /usr/local/bin/vault

Damit das aufrufen von Vault direkt gelingt müssen wir unsere PATH Variable noch um /usr/local/bin ergänzen. Ich hab das ganze in meinem ~/.bash_profile hinterlegt:

PATH=$PATH:$HOME/bin:/usr/local/bin

Wenn alles korrekt ausgeführt wurde, können wir jetzt die Autocompletion nachziehen und anschließend die Shell neustarten:

vault -autocomplete-install
complete -C /usr/local/bin/vault vault
exec $SHELL

Um das ganze abzurunden lassen wir Vault als Daemon laufen.

Zunächst müssen wir es Vault gestatten mlock syscalls ohne der Notwendigkeit von root ausführen zu dürfen:

setcap cap_ipc_lock=+ep /usr/local/bin/vault

Danach legen wir einen nicht priviligierten Systembenutzer an, unter dem der Vault Daemon später laufen soll:

useradd --system --home /etc/vault.d --shell /bin/false vault

Jetzt kommt die systemd Unit:

touch /etc/systemd/system/vault.service

… mit folgenden Inhalt:

[Unit]
Description="HashiCorp Vault - A tool for managing secrets"
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/vault.d/vault.hcl
StartLimitIntervalSec=60
StartLimitBurst=3

[Service]
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitInterval=60
StartLimitIntervalSec=60
StartLimitBurst=3
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

Bevor wir den Daemon starten können, müssen wir ein paar Verzeichnisse sowie eine Konfigurationsdatei anlegen:
mkdir -pv /etc/vault.d/
mkdir -pv /usr/local/share/vault/data/
chown -R vault. /usr/local/share/vault/

touch /etc/vault.d/vault.hcl

Meine Konfigurationsdatei ist als Beispielhaft anzusehen. Sie behinhaltet das nötigste um den Vault Server grundsätzlich starten zu können. Diese sollte entsprechend an das eigene Szenario angepasst werden und unbedingt mit Zertifikaten ausgestattet sein!

storage "file" {
path = "/usr/local/share/vault/data"
}

ui = true

listener "tcp" {
address = "172.28.128.25:8200"
tls_disable = "true"
}

api_addr = "http://172.28.128.25:8200"
cluster_addr = "http://172.28.128.25:8201"

systemd neuladen und den Vault Daemon starten:

systemctl daemon-reload
systemctl start vault

Wenn uns alles geglückt ist, sollten wir unter der Adresse des Servers, mit Angabe des Ports 8200 nun die UI von Vault vorfinden. Damit geht es nun in der Bildstrecke weiter:

Das wars für den ersten Teil der Serie, im zweiten Teil werden wir uns den Aufbau von Vault genauer anschauen und uns der integration von SSH widment. Vault bietet nämlich viele Integrationsmöglichkeiten mit denen sich am Ende die Authentifizierung von sämtlichen Dienste Zentralisiert über Vault steuern lassen. Bis dahin wünsche ich wie immer viel Spass beim Basteln!

Photo from: https://devopscube.com/setup-hashicorp-vault-beginners-guide/

Max Deparade
Max Deparade
Consultant

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn...

SSH – Der Schlüssel zum Erfolg

Seal of ApprovalOder wie man das meiste aus SSH herauskitzelt.

SSH wird von den meisten Sysadmins genutzt, aber selten so wie es genutzt werden sollte.
Die meisten Administratoren verwenden das folgende Kommando Tag ein Tag aus.

ssh-keygen -t rsa -b 4096 -C "dummy_user@fqdn_dummy.com"

Zerlegen wir das Kommando mal in seine Einzelteile und versuchen zu verstehen was diese eigentlich tun.

Der Parameter '-t' gibt an welchen Key-Typ wir rsa/dsa/ecdsa/ecdsa-sk/ed25519 erstellen wollen. Hierbei wird von kleineren RSA-Keys unter 4096 Bits inzwischen abgeraten. DSA ist als unsicher deklariert und sollte auch seit Version 7 von OpenSSH auch nicht verwendet werden. ECDSA ist wegen der NSA ggf. problematisch zum nachlesen hier. So bleibt nur ED25519 welchen ich bei meiner täglichen Arbeit kaum sehe. Dies sollte aber heutzutage der De-Facto-Standard-Key sein, mit dem das obige Kommando aufgerufen wird.

'-b' für die Bits welche verwendet werden sollen. Wenn nun an dieser Stelle die Frage aufkommt mit welcher Bits-Anzahl ED25519 erstellt werden sollte, sei gesagt dass dieser eine festgelegte Länge hat und damit diesen Parameter ignoriert.

'-C' steht für Comment und dieser kann beliebig sein. Zumeist wird hier aber zur besseren Nachvollziehbarkeit von den Admins dieser Welt das Pattern Username@Hostname verwendet, damit man sehen kann für wen dieser Key erstellt wurde.

Im obigen Beispiel fehlt der Parameter '-N' welcher für new_passphrase bzw. das Passwort steht, wenn man den fehlenden Parameter '-N' mit "" ohne Zeichenkette angibt erhält man einen passwortlosen, privaten SSH-Schlüssel. Zusätzlich wird ein öffentlicher Schlüssel erstellt.

Verbessern wir das obige Kommando: ssh-keygen -t ed25519 -N'' -C 'dummy_user@fqdn_dummy.com'

Der Output des Beispiels:

ssh-keygen -t ed25519 -N'' -C'dummy_user@fqdn_dummy.com'
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/dummy
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/dummy.
Your public key has been saved in /root/.ssh/dummy.pub.
The key fingerprint is:
SHA256:14RQXbFyQCtEZfnGN8O7hV4h9hAEY0SYQN9Y0+9TRp8
root@fqdn_dummy.com The key's randomart image is:
+--[ED25519 256]--+
|      .oooO%O+o. |
|        .==o== ..|
|         oo.+o*.o|
|           + *+E=|
|        S . o.=+*|
|         .    .=o|
|             . .+|
|              .. |
|                 |
+----[SHA256]-----+
[root@fqdn_dummy.com .ssh]# ll
total 8
-rw-------. 1 root root 464 Nov 14 22:45 dummy
-rw-r--r--. 1 root root 108 Nov 14 22:45 dummy.pub

Damit hätten wir einen Standard-SSH-Schlüsselpaar, welches zumeist in den Unternehmen vergessen wird, wenn Mitarbeiter das Unternehmen verlassen oder die Abteilungen wechseln und auch durch automatisierte Deployments wird es oft als Karteileiche liegen gelassen.

Wie wäre es wenn wir ablaufende SSH-Schlüsselpaare hätten, welche nach einer gewissen Zeit ablaufen und zwar von selbst?

Was vielen nicht bewusst ist, ist dass dies SSH eigentlich schon von ganz allein kann, nur nutzt es kaum jemand.

Beginnen wir mit dem ersten Schritt und generieren uns eine CA (Certificate Authority).

ssh-keygen -t ed25519 -N '' -C 'ca' -f ca

Da diese CA unser Dreh- und Angelpunkt ist bedarf es Achtsamkeit, damit diese nie in falsche Hände gelangt.

Dank dieser CA können wir nun Zertifikate von Hosts und Benutzern signieren.

Als Beispiel nehmen wir einen Benutzer 'test' welcher sich per SSH an den Host namens ColdMoon anmelden soll.

Wir brauchen also für beide Zertifikate und einen SSH Schlüssel.

Bevor wir es vergessen müssen wir unsere vorher erstellte CA auf unserem SSH Server in der sshd_config als 'TrustedUserCAKeys /etc/ssh/ca.pub' eintragen.

Nun nehmen wir von unserem Benutzer 'test' auf seinem Laptop und den dort bereits erstellten öffentlichen Schlüssel mit dem wir ihm begrenzten Zugriff auf unsere Infrastruktur geben wollen in diesem Fall unser Rechner ColdMoon.

Im Vorfeld haben wir schon den Benutzer auf dem Rechner angelegt, und der Kollege 'test' hat uns seinen öffentlichen Schlüssel per Email geschickt.
Von unserem Vorgesetzten wissen wir das der Kollege 'test' nur 1 Woche ein Praktikum bei uns vornimmt und danach das Unternehmen wieder verlässt.

Auf gehts wir erstellen einen zeitlich begrenzten Zugang:

ssh-keygen -s ca -I Azubi_auf_Zeit -n test -V +1w -z 1 test.pub
Signed user key test-cert.pub: id "Azubi_auf_Zeit" serial 1 for test valid from 2019-11-13T09:00:00 to 2019-11-20T09:00:00

Das Resultat dieses Kommandos ist das wir ein signiertes 'test-cert.pub' erhalten mit eine Lebenszeit von 1 Woche.
Dieses senden wir umgehend unseren Praktikanten zu mit dem Hinweis das er sich mit dem folgenden Kommando nun an dem Rechner ColdMoon anmelden kann.

ssh -i ~/.ssh/test -i ~/.ssh/test-cert.pub test@ColdMoon -v

Ich habe mal den Verbose-Schalter genommen um zu zeigen wie das Zertifikat sich dann gegen ColdMoon anmeldet.

...
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: test ED25519 SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Server accepts key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.242.67 ([192.168.242.67]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
Last login: Thu Nov 14 11:00:14 2019 from 192.168.242.225
[test@coldmoon ~]$

Die Authentifizierung wird nun die gesamte Woche lang funktionieren in der der Praktikant Zugriff auf dem Rechner braucht, danach weil es nur zeitlich begrenzt ist nicht mehr. Damit ist für den Praktikanten kein Zugriff auf unserer Infrastruktur mehr möglich. Dies funktioniert auch mit anderen Hosts oder Services, welchen man nur für einen Zeitraum einen begrenzten Zugriff per SSH geben möchte.

Der Parameter '-V' gibt den Validity_Interval an, also den Zeitraum der Gültigkeit, und der Parameter '-z' eine Serialnumber, welche von uns frei gewählt werden kann.

Dies kann mit den üblichen Systemmitteln automatisiert werden oder per Ansible/Puppet auch auf Systeme verteilt werden.
Schöner ist es noch wenn es ohne viel manuelle Arbeit geht. Dies zeige ich in meinem nächsten Blogpost welcher Vault aus dem Hause Hashicorp zeigt.

Gruss

David

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

Wie bekomme ich bessere Informationen über Züge als die DB

marudor.de screenshotAls reisender Consultant mit Bahncard 100 verbringe ich sehr viel Zeit in Zügen der Deutschen Bahn. Das ist auf der einen Seite erfreulich, denn ich verbringe die Zeit nicht auf der Autobahn. Auf der anderen Seite macht es die Bahn einem manchmal schwer, sinnvoll von A nach B zu kommen. Es soll ja schon einmal vorgekommen sein, dass Züge ausfallen oder zu spät kommen. Möglicherweise ist auch mal ein Zug überfüllt, Klima defekt, Bier alle oder sonst etwas.

Die DB selber bietet für so etwas ja seit einiger Zeit den DB Navigator. Die wichtigsten Daten bekommt man hier auch. Allerdings weiß die Bahn eigentlich über ihre Züge viel mehr als sie uns sagt. Dieses Problem löst sehr gut und schon seit einiger Zeit die Seite marudor.de

Man sieht auf der Seite, wenn man nach einem Bahnhof, einem Zug oder einer Route sucht, ein gute Übersicht über den gewünschten Zug. Hier sieht man auf einen Blick:

  • Reihenfolge der Waggons mit EXAKTER Positon am Bahnsteig
  • ICE Baureihe inkl. Revision (dadurch weiß man auch, ob man alte bequeme oder neue unbequeme Sitze bekommt)
  • Die Postition der Comfortsitze im Zug, so dass man direkt da einsteigen kann (roter Punkt)
  • Die Position von Bordrestaurant, Kinderabteil, Behindertenbereich und -toilette
  • Ruhe und Handy-abteil
  • Wifi Accespoints (und ob er funktioniert)
  • Aktuelle UND vergangene Störungen auf der Fahrt

Teilweise bekommt man diese Infos auch woanders, allerdings sind sie bei marudor meistens aktueller und vor allem alles in einem Rutsch. Und nicht zuletzt: Verspätungen und Verspätungsprognosen sind besser und zuverlässiger.

Warum das alles so ist und wieso der marudor das alles macht kann man hier erfahren. Das Video kommt von der GPN 19 und ist sehr interessant anzuschauen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.