Hallo,
mit sophomorix-passwd -u <USER> --shell /bin/bash kann man bekannerweise die Shell für User aktivieren.
Beim Testen ist mir aufgefallen, das dem User damit allerdings kein Login über das externe Interface (RED) gewährt wird.
Ich vermute, dass ist aus Sicherheitsgründen mit Absicht so, oder?
Wo lässt sich der externe Login für einzelne vetrauenswürdige User erlauben?
Viele Grüße
Andreas
Hallo Andreas!
Bezieht sich deine Frage auf den Zugang zum Server oder zu Linux-Clients?
Beste Grüße
Thorsten
Hallo Thorsten,
Bezieht sich deine Frage auf den Zugang zum Server oder zu Linux-Clients?
Auf den Server. Und durch deine Frage geht mir ein großes, helles Licht auf: Durch den sophomorix-Befehl aktiviere ich ja ausschließlich die Client-Shell, autsch!
Neuer Anlauf: Wie kann ich für einen „gemeinen User“ (student oder teacher) externen Shellzugriff erlauben?
VIele Grüße
Andreas
Hallo Andreas,
SSH auf den Server bekommst Du durch port forwarding von der externen IP des ipfire auf server:22 hin. Von dort aus kannst du z. B. mit “ssh benutzername@domäne -N -L 4000:client-IP:3389” einen Tunnel für RDP aufbauen. Wenn der Tunnel offen ist, kannst Du mit “rdp localhost:4000” eine Remotedesktop-Verbindung zu client aufbauen (Linux kann neben VNC auch RDP). Wenn Du die 3389 durch die 22 ersetzt, sollte sich analog SSH nutzen lassen.
Gruß Jürgen
Hallo Jürgen,
SSH auf den Server bekommst Du durch port forwarding von der externen IP des ipfire auf server:22 hin.
das habe ich eingerichtet. Als root komme ich per SSH-Tunnel in Putty auf alls lokalen Dienste, insbesondere per RDP auf die Windows-Clients.
Nun möchte ich für einige bestimmte Nutzer der Gruppe students bzw. teaches einen Shell-Zugriff von außen ermöglichen, was allerdings nicht klappt.
Die Verbindung nach Eingabe des Passwort wird sofort serverseitig geschlossen. Wo ist konfiguriert, dass nur „root“ Zugriff über „RED“ auf den Server hat?
Viele Grüße
Andreas
Hallo Andreas,
erstmal: der Zugang von außen auf die shell des Servers sollte niemals
per “keyboard” möglich sein, sondern nur per ssh-keys:
https://www.linuxmuster.net/wiki/anwenderwiki:ssh:ssh-keys
Wenn du das eingerichtet hast, dann kannst du auch für einzelne Nutzer
einen ssh-key erstellen und ihnen so den Zugang ermöglichen.
Ich persöhnlich würde das aber niemals machen.
Ich finde keinen Grund der schwer genug wiegt um das große Risiko zu
rechtfertigen.
Vielleicht hast du einen solchen Grund: ich kann es mir kaum vorstellen,
weil das Risiko wirklich immens ist.
Was sollen die den machen können?
LG
Holger
Hallo Andreas,
die User muss man noch in der Date /etc/security/access.conf eintragen. Da gibt es eine Zeile so ähnlich wie „-:ALL but root administrator“, da ergänzt man einfach die gewünschten Usernamen per Leerzeichen getrennt.
Beste Grüße
Jörg
Hallo Holger,
ich hab das für (ausgewählte) Kollegen auch so eingerichtet. Dann können die bequem per WinSCP o.ä. Dateien hin und herschieben.
Wo siehst Du das Sicherheitsproblem?
Viele Grüße,
Jochen
Hallo Jochen.
Warum nicht per NextCloud??
Michael
Hallo Jochen,
ich hab das für (ausgewählte) Kollegen auch so eingerichtet. Dann können
die bequem per WinSCP o.ä. Dateien hin und herschieben.
Wo siehst Du das Sicherheitsproblem?
wenn du ssh-keys verwendest, dann ist das Sicherheitsrisiko nur, wie gut
die ausgewählten KOllegen den Key verwahren.
Einen Server im Internet mit offenem ssh Zugang, der nicht per key
gesichert ist, halte ich selbst bei „nur root“ Zugang für absolut
fahrlässig: dass der gehackt wird, ist nur eine Frage der Zeit.
Das Risiko explodiert, wenn mehr Nutzer als root den ZUgang zur shell haben.
Hast du SSH Keys, dann würde ich die shell der ausgewählten Nutzer auf
„nur SCP“ setzten.
Frag eine Suchmaschine, wie das geht: ich meine es gibt eine scp-only
shell oder sowas.
Der eigentlich vorgesehene Weg für Nutzer ist aber openVPN: das wird von
vielen, wenn es erst mal eingerichtet ist, als viel kompfortabler
angesehen als SCP.
Der Königsweg ist aber sicher die Nextcloud.
LG
Holger
Hallo Michael, hallo Holger,
Nextcloud haben wir an meiner neuen Schule noch nicht. Werde ich aber wohl demnächst hochziehen, dann aber Seafile.
Danke und Gruß,
Jochen
Danke für eure Antworten.
Habe mich dazu entschlossen, den Shell-Zugang nicht einzurichten. Selbst wenn die Nutzer noch so vertrauensselig sind, es reicht aus, dass ihre Zugangsdaten (egal, ob Passwort oder Private Key) durch einen Trojaner o.ä. in die Hände Dritter gelangen und diese so Zugriff aufs grüne Netz bekommen.
Dank für den Hinweis. Werde ich für root einrichten.
Viele Grüße
Andreas
Hallo Jürgen,
Sicherer ist es wohl, wenn direkt über ipfire von Port XYZ auf <Client-IP>:3389 weitergeleitet wird, um RDP nur auf diesem Client zu nutzen. Mittels custom.bat kann der Zugriff für bestimmte Nutzer auf bestimme Clients erlaubt werden:
if "%COMPUTERNAME%"=="<CLIENTNAME>" net localgroup "Remotedesktopbenutzer" <DOMÄNE>\<NUTZER> /add
Viele Grüße
Andreas
Hallo Andreas,
Habe mich dazu entschlossen, den Shell-Zugang nicht einzurichten. Selbst
wenn die Nutzer noch so vertrauensselig sind, es reicht aus, dass ihre
Zugangsdaten (egal, ob Passwort oder Private Key) durch einen Trojaner
o.ä. in die Hände Dritter gelangen und diese so Zugriff aufs grüne Netz
bekommen.
… und vor allem eine shell auf dem Server: und das ist, selbst wenn es
ein Nutzer mit eingeschränkten Rechten ist, ein großes Sicherheitsproblem.
Sag doch mal an, was die NUtzer damit hätten machen können sollen
(schlechtes Deutsch … naja, bin halt Mathe und Chemielehrer 
).
Vielleicht haben wir da Ideen/ Erfahrungen
erstmal: der Zugang von außen auf die shell des Servers sollte niemals per “keyboard” möglich sein, sondern nur per ssh-keys:Dank für den Hinweis. Werde ich für root einrichten.
… besser ist das.
Du mußt den key halt auch dabei haben, sonst geht es im Schunetz auch
nicht mehr „mal schnell“ per ssh auf den Server …
LG
Holger
Telearbeit unter Windows mit eigenem Rechner. RDP schien und scheint mir die sinnvollste Lösung.
Hallo Andreas,
Sag doch mal an, was die NUtzer damit hätten machen können sollenTelearbeit unter Windows mit eigenem Rechner. RDP schien und scheint mir
die sinnvollste Lösung.
also dass die wirklich mit den Rechnern im Netz arbeiten und nicht nur
mit dem eigenen von ZUhause auf die Dateien zugreifen (mittels openVPN)?
… aber das sollte auch per openVPN funktionieren.
Ist halt schwierig: dass der Rechner an dem sie arbeiten sollen auch an
ist und nicht besetzt …
LG
Holger
Hallo Holger,
genau, es müssen alle Programme zugreifbar sein.
Als Alternative fällt mir ein, den Zugriff auf ein virtuelles Windows zuzulassen. Da wir vSphere einsetzen, bedarf dies eines Port-Forwardings auf <IP-VSPHERE-HOST>:443, 902 und 903. Die beiden letzteren für Maus- und Tastatureingaben. Allerdings ist RDP deutlich stabiler als eine Remote-Verbindung auf eine VM unter vSphere.
Meinst du, das wäre sicherer?
Gruß
Andreas
Hallo Andreas,
also dass die wirklich mit den Rechnern im Netz arbeiten und nicht nur mit dem eigenen von ZUhause auf die Dateien zugreifen (mittels openVPN)?genau, es müssen alle Programme zugreifbar sein.
… dann würde ich die Sache so machen:
Als Alternative fällt mir ein, den Zugriff auf ein virtuelles Windows
zuzulassen. Da wir vSphere einsetzen, bedarf dies eines Port-Forwardings
auf |:443, 902 und 903|. Die beiden letzteren für Maus-
und Tastatureingaben. Allerdings ist RDP deutlich stabiler als eine
Remote-Verbindung auf eine VM unter vSphere.>
Meinst du, das wäre sicherer?
nein: ich setzt doch kein offenes RDP ins INternet: das währe fahrlässig.
Damit kommt man zwar erstmal nicht auf den Server: aber man hat ein
Trojanisches Pferd (einen Client im grünen Netz).
Mach es per VPN und dann RDP, so ist nur VPN von außen zugänglich und
RDP nur innen.
Du kannst aber natürlich trotzdem die RDP Clients virtuell machen: dann
laufen sie immer und niemand meldet sich dort an (außer den RDP Leuten)
LG
Holger
Hallo Holger,
danke für deine Expertise.
Andere Frage: Hältst du es für fahrlässig in einem Verwaltungsnetz Apache auf 443 oder auf einem beliebigen anderen Port mit htaccess-Zugriffsschutz für das gesamte htdocs-Verzeichnis fürs Internet zu öffnen, um Webdienste wie MRBS für die Verwaltungsangestellten verfügbar zu machen?
Gruß
Andreas
Hallo Andreas.
Warum packst du nicht alle Webdienste nach orange und machst dann gezielt Portweiterleitungen? MRBS läuft zB bei uns zusammen mit NextCloud auf einer VM im orangen Netz. Die DMZ ist ja genau dafür da.
Schöne Grüße
Michael