Wie in der obigen Frage angegeben, habe ich einen RHEL 6-Server, der für den SSH-Zugriff ausgelegt ist, wobei sich Root standardmäßig nicht über SSH anmelden kann. Wenn ich lokal am Server bin, kann ich mich als Root anmelden, aber nur als Root. Wenn ich versuche, mich als Benutzer anzumelden, blinkt auf dem Bildschirm kurz die folgende Meldung auf:
Last Login: Mon Aug 24 08:24:52 on tty1
no directory: /home/user1!
logging in with home="/"
login: no shell: Permission denied
Ich erhalte die Meldung „Keine Shell“, weil keine Shell vorhanden ist /.
Was mich jetzt aber wirklich verwirrt, ist, dass das Home-Verzeichnis tatsächlich existiert, eine gültige Shell enthält und meines Wissens nach die richtigen Berechtigungen hat ( 755). Dies ist bei allen Benutzern der Fall, die auf dieser Serverinstanz existierten und erstellt wurden. Es scheint egal zu sein, ob ich beim Erstellen eines Benutzers einen Pfad zum Home-Verzeichnis definiere oder den Standardpfad übernehme und ihn automatisch zuweise.
Ich habe nichts Ungewöhnliches im Sicherheitsprotokoll oder im Nachrichtenprotokoll gefunden, nur dass der Benutzer sich erfolgreich angemeldet hat (was er auch hat, aber ohne Shell nichts tun kann).
Ich hoffe, dass ich an diesem Punkt keine Neuinstallation durchführen muss, aber es befinden sich fast keine Daten auf dem Server, die verloren gehen würden, wenn dies die einzige Option ist.
Ich wäre für jede Hilfe sehr dankbar, da ich nun schon seit einer Woche erfolglos suche und es versuche.
Bearbeiten:
Ich habe den useradd user1Befehl ursprünglich verwendet, um den Benutzer hinzuzufügen, als dies zu den oben genannten Problemen führte, habe ich verwendet
mkdir /home/user1 && useradd user1 -d /home/user1 && chown -R user:user1 /home/user
Wenn ich den cat /etc/passwd | grep user1Befehl ausführe, erhalte ich:
user1:x:513:517::/home/user1:bin/bash
und wenn ich den ls -l /homeBefehl ausführe, lautet der Eintrag für diesen Benutzer:
drwxr-xr-x. 4 user1 user1 4096 Aug 19 17:03 user1
Antwort1
Ich konnte das Problem beheben, indem ich den Befehl ausführte
for p in $(rpm -qa); do rpm --setperms $p; done
und den Server neu starten. Nach dem Neustart konnte ich mich nicht nur als jeder beliebige Benutzer anmelden, der angelegt worden war, sondern auch die GUI wieder verwenden. Dies deutet auf beschädigte Dateiberechtigungen irgendwo im System hin. Wie sie beschädigt wurden, weiß ich nicht, aber jetzt funktioniert alles.
Antwort2
Das einzige Problem, das ich bei Ihrem Setup sehe, liegt in Ihrer Passwd-Datei. Versuchen Sie,
user1:x:513:517::/home/user1:bin/bash
sie in zu ändern user1:x:513:517::/home/user1:/bin/bash.
Antwort3
Das Home-Verzeichnis sollte useradderstellt werden, wenn die richtige Option angegeben wird, und Sie müssen es nicht (oder sollten es nicht) manuell erstellen. Ich schlage vor, dass Sie Folgendes (in der angegebenen Reihenfolge) ausführen, um Ihren Benutzer ordnungsgemäß zu entfernen und neu zu erstellen.
userdel -f -r user1
useradd -m user1
HINWEIS: Sie müssen die Option nicht übergeben, da in diesem Fall -ddie Standardeinstellung lautet ./home/user1
Antwort4
Ich hatte gerade dasselbe Problem auf einer CentOS 6-Maschine. Es handelte sich um ein Problem mit Dateien in /home, die falsch beschriftete SELinux-Sicherheitskontexte hatten. Einer der Kommentatoren oben, Michael Hampton, der sagte, man solle /var/log/audit/audit log überprüfen, hatte vollkommen recht. Ich befolgte seinen Rat und bemerkte, dass hier ein SELinux-Problem vorlag. Die Lösung, die das Problem für mich behoben hat, war:
sudo restorecon -Rv /home
Dadurch werden die Standard-Sicherheitskontextbezeichnungen für alle Dateien im Home-Verzeichnis rekursiv wiederhergestellt. Danach wurde der SSH-Zugriff über den öffentlichen Schlüssel wiederhergestellt.