Login an der Konsole nur für root erlauben

Beim SSH-Login wird die /etc/profile aber auch eingelesen, also sind die doch mit deiner Methode auch betroffen, oder sehe ich da was falsch? Schliesslich wird beim SSH-Login die Bash als Login-Shell gestartet.
 
Nein. Das Skript prüft ja auf die TTY und sobald diese nicht der Konsolenanmeldung entspricht, passiert nichts weiter. ;)
SSH ist ja sehr gut skalierbar, somit kann ich dezidiert über die SSH Konfiguration steuern wer sich einloggen darf und wer nicht.
 
Stimmt, die TTY-Abfrage hatte ich nicht beachtet. Also muss derjenige an deinem Rechner nur einmal Alt+F2 drücken und kann sich dann doch auf der Konsole anmelden. :D
 
Klugscheisser :D

Das neue Skript schaut jetzt so aus:
Code:
TTY=$(tty)
echo $TTY > TTY
TTY_NEW=$(cat TTY | cut -c 1-8)
rm -f TTY

if [ "$TTY_NEW" = "/dev/tty" ]; then
        if [ "$UID" = "0" ]; then
          echo "Anmeldung fuer root erfolgreich!"
        else
          echo "Die Konsolenanmeldung ist nur fuer root erlaubt!"
          logout
        fi
fi
Einwände wie immer gerne willkommen. :D
 
Ok, so kann es funktionieren, auch wenn mir der Sinn hinter der Sache immernoch nicht klar ist.
 
Den hab ich ja schon weiter oben erklärt ;)
siehe http://www.unixboard.de/vb3/showpost.php?p=325395&postcount=13

Ein Problem dabei habe ich allerdings noch entdeckt. Wenn ein User schnell ist und sofort nach der Anmeldung STRG+C drückt, kommt er rein bevor die /etc/profile abgearbeitet wird. Die Abfrage am Anfang von /etc/profile einzusetzen beschleunigt die Sache zwar, aber es ist trotzdem noch möglich wenn man sehr schnell ist. Muss ich mir noch anschaun... Ev. das ganze als Startupskript ein einer Schleife laufen lassen. Die Frage ist nur: Wie kann ich einen User aus ner Shell werfen?
 
Indem du seinen bash-Prozess killst. Aber wenn schon sowas auftaucht, würde ich an deiner Stelle doch lieber eine sichere Lösung suchen.
 
Lest doch einfach mal Vorschläge wie zum Beispiel meinen (Erinnerung: PAM) durch, man kann PAM für die einzelnen Dienste (ssh, login, etc.) unterschiedlich konfigurieren und entsprechend User beim einen oder anderen Dienst ausschliessen.

EDIT: Und ich habe immer noch nicht verstanden, wo der Vorteil ist, wenn die Leute über SSH reinkönnen, dann ist doch auch die Virtuelle Konsole total egal. Sorry, aber deine Beschreibung habe ich nicht verstanden. Und wo SSH da flexibler ist verstehe ich nicht. Ich hätts gern deutlicher erklärt..?
 
Ehrlich gesagt denke ich schon, dass ich das nachvollziehbar erklärt habe.

Das Problem ist, der Server hängt in einer Windows Domäne!
Daher habe ich keine lokalen User auf dem Server, alleine deshalb fällt sowas wie /bin/nologin oder ähnliches weg, weil ich da nicht 3000 User eintragen kann bzw. verständlicherweise nicht will! Jeder Depp könnte sich dadurch theoretisch auf dem Server anmelden.
Per SSH kann ich durch AllowUsers bzw. AllowGroup genau einstellen wer darf und wer nicht. Somit dürfen sich wirklich nur noch diejenigen Personen am Server anmelden die auch wirklich dürfen. Wie gesagt, das Zauberwort lautet Windows Domäne!

Und für mögliche Beispiele einer konfiguration mit PAM oder dergleichen bin ich gerne offen, nur ich habe mit Google und Co. nix gefunden (wie ich ja schon erwähnt habe). Wenn es also in einer anderen Richtung konkrete Vorschläge gibt, dann bin ich natürlich offen dafür.

Folgendes Startskript werde ich jedenfalls noch hinzufügen:
Code:
while

  CUSER_PID=$(ps -U root -u root -N |grep tty |cut -c 1-5)

  if [ "$CUSER_PID" = "" ]; then
     echo "Kein User eingeloggt"
  else
     echo "Sie sind nicht root und werden ausgeloggt!"
     kill -9 $CUSER_PID
  fi

do sleep 2

done
 
Deshalb sagte ich ja auch, ich habe es nicht verstanden, weil es für mich nicht verständlich war. Danke für die Aufklärung. Dein Problem ist also nicht, den Login an der Konsole zu verbieten sondern generell nur bestimmte Benutzer auf das System zu lassen, richtig?

Das lässt sich mit pam_listfile lösen. Dazu gibt es eine Manpage und zur generellen PAM-Konfiguration findet man auch genug Infos. (Übrigens kann man das auch Benutzen um die TTY einzuschränken, wenn man denn will..
 
ok danke, werde ich mir anschaun. ;)
Aber ich muss ehrlich zugeben, meine Lösung gefällt mir so sehr gut... denke schon, dass das Securitytechnisch in Ordnung ist. Oder fallen Euch da Einwände ein?
 
Zuletzt bearbeitet:
Wie du selbst schon anmerktest, kann man das Ausführen der /etc/profile durch ein schnelles Strg+C unterbrechen. Ein kleines Zwischenstück zu basteln, das man zwischen Tastatur-Anschluss und Tastatur-Stecker packt und das nach einer bestimmten Anzahl Tastendrücken (Benutzernamenlänge+1+Passwortlänge+1) einen solchen Interrupt sofort sendet, dürfte nicht wirklich problematisch sein und schon ist dein "Schutz" total nutzlos.
 
@bitmuncher
*seufz*
Irgendwie ist das frustrierend, denn man merkt das du dir das Thema nicht richtig durchgelesen hast...
Folgendes Startskript werde ich jedenfalls noch hinzufügen:
Code:
while

  CUSER_PID=$(ps -U root -u root -N |grep tty |cut -c 1-5)

  if [ "$CUSER_PID" = "" ]; then
     echo "Kein User eingeloggt"
  else
     echo "Sie sind nicht root und werden ausgeloggt!"
     kill -9 $CUSER_PID
  fi

do sleep 2

done

So oder so, ich werde mir das mit pam_listfile jedenfalls auch noch anschaun.
 
Zuletzt bearbeitet:
Ein Startskript wird nur einmal ausgeführt und im Loop blockiert es den Startprozess im schlimmsten Fall. Es müsste als Cron-Skript laufen, womit der User wiederum mindestens eine Minute Zeit hat noch Dinge im System zu machen, wenn er sich im richtigen Moment einloggt. Diese Dinge könnten auch das Überlasten des Cron-Prozesses mittels User-Cron sein. Ich halte diese Möglichkeit einfach nicht für sicher, sowas via Skript abfangen zu wollen. Sowas muss direkt im Authentifizierungs- oder Loginsystem abgefangen werden, damit es wirklich sicher ist. Da kannst du seufzen soviel du willst. Gib mir die Kiste unter die Finger, wenn du sie via Skript "gesichert" hast und mit min. 90% Wahrscheinlichkeit finde ich eine Möglichkeit es zu umgehen. Z.B. logge ich mich via SSH ein, suche oder bastel mir ein nettes lokales Exploit und verpasse meinem User die UID 0 bevor deine Skripte greifen können o.ä. Möglichkeiten gibt es viele.
 
Zuletzt bearbeitet:

Ähnliche Themen

Keine grafische Oberfläche (Debian Installation)

So, das wars nun endgültig mit Centos und Linux

nginx owncloud, php? Problem

openn SuSE 13.1 - 64-BIt erlaubt nicht mehr als 20GB für /root

vsftpd: internet explorer problem

Zurück
Oben