Nutzerrechte beschränken

[guennid]

Ich möchte erreichen, dass ein per ssh ohne Passwort eingeloggter Benutzer nichts darf außer

Code: Alles auswählen

su

Geht sowas?

Grüße, Günther

[pferdefreund]

Bestimmt - und wenn man am Quelltext der Shell oder was auch immer drehen muß. Wir haben hier open source.
Aber für mich stellt sich die Frage - warum ? Eventuell kann man das auch anders lösen. Kann man dem Nutzer eventuell einfach su als shell vergeben ? - und wenn er nur su darf, kann er ja auch su mein-nutzer machen und hat dann doch wieder ne shell.

[uname]

Gib ihm die Shell /bin/su in /etc/passwd. Alternativ kannst du in /home/<user>/.ssh/authorized_keys mit command="/bin/su ..." den Zugriff über den SSH-Key beschränken. In beiden Fällen wird direkt /bin/su ausgeführt. Evtl. musst du für den Benutzer sftp sowie SSH-Port-Forwarding noch deaktivieren.

Was möchtest du genau erreichen? Die Eingabe des root-Passworts über einen Umweg? Nicht gut. Ich habe vor einiger Zeit aus Spaß mal ein paar sinnlose Restricted-Shells auf Basis von tmux und screen programmiert. Als Shell habe ich dann jedoch keinen Befehl, sondern ein Script verwendet.

[guennid]

Was möchtest du genau erreichen?

Erst mal: Dank an euch beide für das Interesse!

Ich bin kein Nerd (und der Begriff Nerd ist bei mir nicht negativ konnotiert ). Ich mach' mir halt so meine Laien-Gedanken.

Konkret: Ich habe zwei Stretch-Maschinen für Spezialaufgaben: einen Fernseher+Videorecorder und einen Radioapparat. Der "einzige" User wird beim Maschinenstart automatisch grafisch eingeloggt. Ich administriere die Maschinen via ssh. Seit geraumer Zeit geht auf mindestens einer der beiden Maschinen kein unmittelbares root-login mehr. Folgsam wie ich bin, akzeptiere ich dieses vermutliche Sicherheitsfeature (ich weiß, wie man's abstellt). Und so kam mir die Idee, mich nicht als dieser eine User per ssh einzuloggen (bei dem ich dann immer erst den Xserver killen muss), sondern einen zweiten anzulegen, der dann eben ausschließlich als root fungiert, sich aber nicht als solcher per ssh einloggen darf.

Wahrscheinlich wie häufig bei mir um viel zu viele Ecken gedacht.

Grüße, Günther

[MSfree]

Und so kam mir die Idee, mich nicht als dieser eine User per ssh einzuloggen (bei dem ich dann immer erst den Xserver killen muss)

Warum mußt du den Xserver killen?

Ein Remote-Login via SSH hat doch gar nichts mit dem laufenden Xserver zu tun. Ich kann mich problemlos als normaler User per SSH auf meinen Linuxen einloggen, gefolgt durch su und los get die Administration. OK, natürlich nur im Textmodus von der Kommandozeile, aber was ausser apt-get braucht man schon für die routinemässige Administration?

[guennid]

Der "einzige" User wird beim Maschinenstart automatisch grafisch eingeloggt.

[MSfree]

Der "einzige" User wird beim Maschinenstart automatisch grafisch eingeloggt.

Gelesen habe ich es, aber verstehen tu ich es immer noch nicht. Auf dem Videorekorder läuft also ein Xserver mit Autologin. So weit so gut.

Von einem anderen Rechner logst du dich als WerAuchImmer auf dem Videorekorder ein. Was hat das dann mit dem Xserver zu tun? Von der Shell, die du in der SSH-Session bekommst, kannst du doch ganz normal mit su weitermachen.

[uname]

Bei Autologin sollte es reichen alle Prozesse des aktuellen Benutzers zu killen:

Als Anwender:

Code: Alles auswählen

kill -9 -1

Als root:

Code: Alles auswählen

pkill -u <user>

Natürlich könntest du auch einen Benutzer anlegen, der automatisiert als root die Prozesse des anderen Benutzers killt. Vielleicht mit sudo.

[MSfree]

Bei Autologin sollte es reichen alle Prozesse des aktuellen Benutzers zu killen:

Warum sollte man überhaupt auch nur einen einzigen Prozeß killen?

su und gut! Man ist sofort root und kann administrieren. Ggfls. muß man nach getaner Arbeit auch mal einen Dienst mit systemctl neu starten, die laufenden Prozesse berührt das aber nicht im geringsten, die können alle ohne kill so weiterlaufen wie vorher..

[uname]

Warum sollte man überhaupt auch nur einen einzigen Prozeß killen?

Weil da was von X-Server killen stand. Hatte gedacht, dass der öfter mal einfriert und das die eigentliche Administration sei. War wohl eine falsche Annahme.

[guennid]

Wie schon gesagt, ich bin kein Nerd/Fachmann. MIt Killen meinte ich hier nicht das Kommando kill.

Ich erlebe das so: Den "Fernseher"/das "Radio" bedienen, das muss ein User (user1) machen, wozu (zumindest beim "Fernseher") eine GUI erforderlich ist. Das mache ich per autologin dieses Users beim Systemstart. Und eigentlich gibt's keinen Bedarf für die Einrichtung eines weiteren "normalen" Benutzers auf dem System. Logge ich mich aber nun nochmals als user1 per ssh auf dem laufenden System ein, dann funktioniert das zwar mit dem Kommando

Code: Alles auswählen

ssh -X User1@rechnername

. Versuche ich mich dagegen mit

Code: Alles auswählen

ssh user1@rechnername

einzuloggen (ich will ja root werden, brauche ergo kein X) dann funktioniert das wegen des laufenden X-servers für diesen User nicht. Ich muss den "Prozess"/was weiß ich, mit Strg+c abbrechen. Deswegen die Idee mit dem zweiten User, der aber eigentlich nur als root tätig werden soll.

[uname]

Warum sollte man sich nicht per SSH anmelden können. Du musst evtl. den Autostart ändern.

[guennid]

Code: Alles auswählen

Du musst evtl. den Autostart ändern.

Warum sollte ich das bei einem "Fernseher"/"Radio" tun?

Eher werde ich denn ssh-login für root aktivieren. Das wollte ich vermeiden.

Grüße, Günther

[MSfree]

... Versuche ich mich dagegen mit

Code: Alles auswählen

ssh user1@rechnername

einzuloggen (ich will ja root werden, brauche ergo kein X) dann funktioniert das wegen des laufenden X-servers für diesen User nicht.

Da stellt sich mir aber die Frage, warum das nicht geht.

Ich kann mich an meinen Rechner immer mit SSH anmelden, egal ob da bereits ein Xserver läuft und der gleiche User angemeldet ist. Irgendwas ist da bei dir komisch, denn das muß eigentlich funktionieren.

Ob man ssh nun mit -X oder ohne verwendet, hat auch nichts mit dem laufenden Xserver zu tun. Die Idee hinter dem -X ist, daß man auf dem Fernseher eine X-Anwendung starten kann, die dann über ssh getunnelt wird und auf dem Bildschirm, auf dem man den ssh-Client gestartet hat, angezeigt bekommt. Und selbst, wenn der ssh-Client auf dem selben Rechner gestartet wird, auf den man mit ssh zugreifen will (was allerdings einigermassen sinnbefreit wäre, da kann man auch gleich su in ein Xterm tippen), funktioniert der ssh-Aufruf mit und ohne -X, zumindest bei meinen Kisten.

Für mich klingt die ganze Sache nach schräg konfigurierten ssh-Servern und/oder ssh-Clients.

Hast du schonmal mit

Code: Alles auswählen

ssh -vv user@rechner

probiert? Da kommt dann einiges an Diagnosemeldungen, die Aufschluß über das Problem geben können.

[guennid]

Danke für den Tipp mit -vv!!

Vielleicht immer noch missverständlich: Ich wollte nicht sagen, dass das login mit: ssh user1@rechnername gar nicht funktioniert, im Gegenteil: es funktioniert - nachdem ich Strg+C gedrückt habe. Du bringst mich da aber auf eine neue Idee. Clientseitig sitze ich (natürlich?) vor einer GUI. Die Idee, clientseitig von der Konsole aus mit ssh einzuloggen, ist mir bisher noch nicht gekommen. Find' ich zwar nicht besonders kommod, aber testen werde ich's.

Grüße, Günther

[MSfree]

Du bringst mich da aber auf eine neue Idee. Clientseitig sitze ich (natürlich?) vor einer GUI.

Das ist bei mir auch so.

Die Idee, clientseitig von der Konsole aus mit ssh einzuloggen, ist mir bisher noch nicht gekommen.

Ich starte den ssh-Client normalerweise aus einem Xterm heraus, also auch von der GUI.

Vielleicht solltest du auch mal die Datei ~/.ssh/config unter die Lupe nehmen, sofern du diese mal angelegt haben solltest.

[jph]

Logge ich mich aber nun nochmals als user1 per ssh auf dem laufenden System ein, dann funktioniert das zwar mit dem Kommando

Code: Alles auswählen

ssh -X User1@rechnername

. Versuche ich mich dagegen mit

Code: Alles auswählen

ssh user1@rechnername

einzuloggen (ich will ja root werden, brauche ergo kein X) dann funktioniert das wegen des laufenden X-servers für diesen User nicht

Du hast den Usernamen mal mit kleinem, mal mit großem U geschrieben. Tippfehler? Benutzernamen sind case-sensitive, d.h. User1 ist wer anders als user1!

Es wäre hilfreich, wenn du uns die exakte Meldung nenntest, anstelle Spekulationen über den X-Server anzustellen.

[guennid]

War ein Tippfehler, 'Tschuldiung!
Aber das hier ist das Phänomen:

Vielleicht immer noch missverständlich: Ich wollte nicht sagen, dass das login mit: ssh user1@rechnername gar nicht funktioniert, im Gegenteil: es funktioniert - nachdem ich Strg+C gedrückt habe.

Ich muss, wenn ich recht sehe, auf der Client-Seite mit Strg+c sagen, dass ich keinen Wert auf Das X der Maschine des des ssh-servers lege, oder wie immer das der Fachmann interpretiert. Und guennid-spezial konfiguriert an ssh habe ich, soweit ich erinnere, eigentlich nichts. Insofern wundert mich, dass MSfree sich wundert. Ich finde das sshd-Verhalten bei mir, soweit ich glaube, es zu verstehen, eigentlich ziemlich logisch.