Restricted Shell gesucht

SiS

SiS

Routinier
Hallo,

bin gerade am Absichern eines Arch Servers (erstmal nur Übungszwecke und nur im heimischen Netz).
So ich habe einen User erstellt mit dem ich mich per SSH einloggen kann.
Der einzige Zweck dafür ist aber per "su" zum Root zu werden.
Andere Programme oder Zugriffe (vorallem außerhalb seines Home-Verzeichnisses) würde ich gerne sperren.
Unter Debian gabs /bin/rbash...
Gibts was vergleichbares unter Arch? Oder vielleicht was noch besseres? :)

Danke schonmal...
 
Zuletzt bearbeitet:
Ja, rbash wäre auch das erste was mir einfallen würden. Gibts das nicht in den Quellen von Arch?
 
Code:
<root> (/home/sim4000) pacman -Ss shell
extra/rssh 2.3.2-2
    A restricted shell for use with OpenSSH, allowing only scp and/or sftp
Aber ohne Garantie, dass es das richtige ist. Habs nur beim suchen gefunden. :)
 
@sim: rssh hatte ich auch schon gefunden. Aber das sieht eher danach aus, als wär das für scp bzw. sftp, also Dateiübertragungen...

@aspire:
Ne offensichtlich nicht. Auch im AUR findet sich nichts...
 
chroot

Pack deinen User doch einfach in eine chroot-Umgebung und "installiere" dort nur die Programme die du nutzen willst.

Aber sei da nicht zu restriktiv - auch auf einem Server kannst du als normaler User schon viel erledigen.
 
Und wenn ich mich dann über diesen User zum Root machen will? Sitze ich dann immer noch im chroot oder hab ich dann Vollzugriff? Hab bisher noch nicht wirklich mit chroot gearbeitet...
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Ah selber draufgekommen...
Ein einfaches "ln /bin/bash /bin/rbash" hats gebracht. Wenn bash als rbash aufgerufen wird wird es automatisch restricted.

Aber wirklich was bringen tut das nicht...man kann zwar nicht mehr in andere Verzeichnisse wechseln aber Zugriff hat man trotzdem noch...

Ich schau mir dann mal eher chroot an...

Danke nochmal für die Antworten ;)
 
Zuletzt bearbeitet:
Danke! Klappt :)
Ich hab glaub ich mal wieder zu kompliziert gedacht :D

Sicherheitstechnisch müsste das ja denk ich auch in Ordnung sein, wenn nicht sogar besser oder nicht?
 
IMHO bringt die ganze Aktion im Hinblick auf Sicherheit so oder so nichts.

Welchen Sinn soll es haben einem normalen User rechte wegzunehmen, wenn der einzige Grund der "User"-shell ist, root zu werden?

Als root kann er sicher sehr viel mehr Unsinn machen.

//Edit: Unsinnigen Satz geändert:

Sicherheitstechnisch ist su als login-shell auch kein Gewinn, denn nun muss der sich einloggende User als root arbeiten, egal, was er machen will und egal, ob er dazu root-Rechte benötigt oder nicht.

Aber, da es aus Blickwinkel Sicherheit eh nur eine vernünftige Absicherung gibt, namentlich "da darf kein unberechtiger Nutzer reinkommen, egal mit welcher shell" sind wir wieder am Ausgangspunkt, welchen Sinn das ganze haben soll.
 
Zuletzt bearbeitet von einem Moderator:
Ich hatte die Idee halt aus dem Securing Debian Howto. *klick*

Sicherlich bringt es nicht wirklich viel, aber doch bestimmt schonmal ein bisschen.
 
Sicherlich bringt es nicht wirklich viel, aber doch bestimmt schonmal ein bisschen.

In Deinem Szenario bringt es gar nichts, im Gegenteil (siehe Edit meines letzten Posts).

//Edit:

Und in dem verlinkten HowTo steht auch nichts zu rbash, zumindest nicht im SSH-Abschnitt, wohl aber etwas zu SSH und chroot, nur ist das für Dein Szenario eben ungeeignet.
 
Zuletzt bearbeitet von einem Moderator:
Eine restricted shell sollte es auch einfach mit

Code:
bash -r

geben.
 
Gut im allgemeinen wird halt immer gesagt kein Root Login per SSH. Ich bezog mich halt vorallem auf den Teil "PermitRootLogin", deshalb wollte ich halt einen User mit dem man möglichst nichts machen kann. Ich denk nochmal drüber nach und informier mich noch ein bisschen...
 
Gut im allgemeinen wird halt immer gesagt kein Root Login per SSH.

Stimmt ja auch.

Ich bezog mich halt vorallem auf den Teil "PermitRootLogin", deshalb wollte ich halt einen User mit dem man möglichst nichts machen kann.

Hm, was hat das Eine denn mit dem anderen zu tun?

Ich sehe da jedenfalls keinerlei Zusammenhang, welche Nachteile dieser "Stunt" (vor allem der mit /bin/su als loginshell) hat, wurde Dir ja schon in den vorherigen Postings (5 und 9) gesagt.

Für mich ist das in etwa so wie

"Wir nehmen dem Wachmann drüben aus Sicherheitsgründen mal lieber den Schlagstock und das Funkgerät weg, aber den Schlüssel zur Waffenkammer darf er behalten."

Nur is es nun mal so, daß er eben den Schlüssel zur Waffenkammer braucht (root Passwort), wenn er seinen Job auch im Notfall erledigen will, er aber mit dem Schlagstock und Funkgerät sehr wahrscheinlich oft genug auskommt.

Sinnvoller wäre es die Waffenkammer nur dann aufzuschliessen, wenn man sie auch wirklich braucht.
 
Zuletzt bearbeitet von einem Moderator:
Hmm ja gut das klingt soweit eigentlich logisch. Ich werd mal drüber nachdenken, aber erst später (war in der Schule in Sankt Augustin. Wens interessiert -> Nachrichten gucken)
 

Ähnliche Themen

[Samba] Probleme mit SymLinks und Mount

RSSH für sFTP - ChRoot-Umgebung

[HowTo] TeamSpeak 2 - RC2 - Server (Deutsch/Englisch)

Zurück
Oben