Ssh anderer Port - wie erfährt der Master davon?

UCS - Univention Corporate Server
#1

Guten Abend,

Ich habe auf meinem System (UCS-Slave) den SSH-Port geändert - damit bekomme ich aber eine kritische Systemfehlerdiagnose…

Jemand eine Idee?

Grüße,
Bernd

#2

Hallo Bernd,

Du könntest auf dem Master für den root eine ~/.ssh/config anlegen und dort drin die Verbindung konfigurieren. Siehe https://wiki.ubuntuusers.de/SSH/

# ssh (secure shell) configuration file
Host test1
    HostName 123.456.789.0
    Port 980
    User MeinBenutzerName

Host test2
    HostName test.mynet.local
    User test

Viele Grüße
Ulf

#3

Hallo Ulf,

danke für die Idee - ja, das könnte man evtl. so machen.
Problematisch könnte sein: ich gehe nicht davon aus, dass die Systemfehlerdiagnose von root aus gestartet wird?! Das ist zumindest meine Hoffnung, wahrscheinlich vom Admin-User, der angemeldet ist? Schön wäre eine ucr Variable :slight_smile:

Grüße,
Bernd

#4

Huhu,

Ich bin mir sogar im Gegenteil ziemlich sicher, dass diese als root ausgeführt wird, weil sie einige Daten lesen muss, die nur root zugänglich sind. Die komplette UMC ist als Client-Server-Modell ausgelegt: der UMC-Server läuft als root, um alles machen zu können (allein schon Systemupdates), und der ganze Frontend-Code im Webserver ist hier der “Client”, der dann nur als nicht privilegierter User www-data läuft.

Siehe ps uaxw | grep management-console.

UCR-Variablen sind immer Server-lokal. Das Problem ist aber gerade, dass man auf allen anderen Servern wissen muss, auf welchem Port der SSH-Server läuft. Genaue: würde man auf Server A den SSH-Port mittels UCR-Variable auf einen anderen ändern, so müssen Server B, Server C etc. genau wissen, wie die UCR-Variable auf Server A gesetzt ist. Dafür ist der UCR-Mechanismus schlicht nicht gedacht. Verteilte Informationen müssten hingegen im LDAP stehen.

Was viel sinniger wäre, wäre die Verwendung von SRV-DNS-Records dafür, denn die sind a) in der ganzen Domäne abfragbar und b) genau für so etwas gedacht. Siehe z.B. host -t srv _ldap._tcp.$(ucr get domainname). Allerdings glaube ich kaum, dass das in UCS implementiert ist.

Edit: OK, SRV-Records sind eigentlich dafür da, den Host & die Portnummer für einen Dienst in der Domäne zu finden, sprich »welcher Server bietet LDAP auf welchem Port an?« — und nicht »auf welchem Port läuft SSH auf Host XYZ?« Also doch nicht ganz die ideale Lösung :slight_smile:

Gruß
mosu

#5

Hallo mosu,

danke für die Erklärung! Ja, das macht Sinn.
Es gibt wohl Wünsche in dieser Art siehe https://lists.debian.org/debian-ssh/2014/03/msg00041.html

Bis dahin nehme ich ~/.ssh/config oder lasse es auch erstmal bleiben. Letztlich ist die Fehlermeldung wohl im Betrieb auch nicht sonderlich relevant?

Grüße,
Bernd

#6

Huhu,

Oh doch, die ist sehr wohl relevant. Es gibt mehrere Sachen, für die ein Server per ssh auf einen anderen Server verbinden muss — z.B. werden die SSL-Zertifikate auf die DC Backups darüber synchronisiert, und beim Joinen neuer Server werden jede Menge Daten darüber abgeholt.

Warum wollen Sie den Port überhaupt ändern? Aus vermeintlichen Sicherheitsgründen? Ich würde aufgrund der zu erwartenden Komplikationen sehr davon abraten, den Port zu ändern. Falls der Server aus dem Internet via ssh erreichbar sein soll, aber nicht auf dem Standard-Port, dann sehe ich da zwei Möglichkeiten:

  1. Falls der Server hinter einem Router steht: einfach auf dem Router einen beliebigen, hohen Port (z.B. 37192) auf Server:22 forwarden (der muss extern und intern ja nicht identisch sein)
  2. Den ssh-Server einfach gleichzeitig auf zwei verschiedenen Ports lauschen lassen (dafür die Vorlage /etc/univention/templates/files/etc/ssh/sshd_config anpassen und zwei Port-Zeilen daraus machen, das geht)

Nur, damit meine Aussage von vorhin nicht misverstanden wird: es gibt übrigens in der Tat eine UCR-Variable, um den ssh-Server auf einem anderen Port lauschen zu lassen: sshd/port. Aber das löst halt nicht das Problem, dass andere Server nichts über diese UCR-Variable wissen.

Gruß
mosu

#7

Nabend again,

verbuche ich mal unter “im Betrieb nicht sonderlich relevant” :wink:
Aber Spaß beiseite - ja, ich überlege das nochmal, was ich da mache - klar, die Sicherheit… Die sshd/port Variable habe ich gefunden und auch darüber den Port geändert. Und wenn das alles so gut über openvpn funktioniert wie derzeit, gibt es vielleicht auch keinen Grund die ssh-Sitzungen nicht auch einfach darüber zu starten.
Bzw. ist ja da Ihr Tipp mit den beiden Ports auch relevant.

Danke! Beste Grüße,
Bernd

Mastodon