SSH ohne Sourcing .bashrc
Ich habe mit meiner .bashrcDatei experimentiert, während ich mich über SSH remote bei einem Server angemeldet habe. Ich habe versehentlich ein drin gelassen exit, das dazu führte, dass alle nachfolgenden Anmeldungen sofort getrennt wurden. Ich wurde effektiv ausgesperrt. Ich konnte den Zugriff durch Eingreifen von jemandem mit Root-Rechten wiederherstellen, aber wäre dies ohne die Hilfe eines anderen möglich gewesen?
Ich habe versucht, Dinge wie Laufen ssh <server> 'bash --norc --noprofile'und zu tun ssh <server> 'mv .bashrc bashrc-backup', und sogar versucht, es mit Gewalt zu überschreiben scp empty-file <server>:.bashrc. Alle diese Optionen scheinen jedoch darauf zu beruhen, dass zuerst die defekten Daten gefunden werden, .bashrcbevor der Befehl ausgeführt wird. Daher hat keine von ihnen funktioniert.
Es kann durchaus sein, dass es keinen Ausweg aus einer solchen Situation gibt. Aber ist das beabsichtigt? Gibt es einen Grund, warum es so einfach ist, sich ein System auszusperren, z. B. nur durch Ausführen ssh <server> 'echo exit > .bashrc'? Gibt es Möglichkeiten, diese Art von Fehler zu mildern?
Antworten
Wie in der anderen Antwort erläutert, startet der OpenSSH-Server beim Herstellen einer Verbindung zum OpenSSH-Server im Allgemeinen eine Shell-Sitzung im Namen des Clients mithilfe der Anmeldeshell des Benutzers:
- Wenn der Client eine interaktive Sitzung anfordert, startet der Server die Anmeldeshell des Benutzers.
- Wenn der Client die Ausführung eines Befehls anfordert, verwendet der Server die Anmeldeshell des Benutzers, um den Befehl als Shell-Befehl auszuführen.
- Dienstprogramme wie
scp,rsyncund,gitdie ssh für den Transport verwenden, fordern die Ausführung eines Befehls auf dem Remote-System an, sodass sie unter # 2 fallen.
Wenn sich in den Shell-Startdateien des Remotebenutzers etwas befindet, das zum Beenden der Shell führt, haben Sie Probleme beim Einsteigen.
SFTP ist jedoch ein Sonderfall. Der OpenSSH-Server kann so konfiguriert werden, dass er SFTP unterstützt, ohne einen externen Befehl zu starten. Wenn dies der Fall ist, können Sie mit sftp eine Verbindung zum Server herstellen und die .bashrcDatei, die das Problem verursacht, löschen, umbenennen oder ändern .
Dies hängt davon ab, wie der Server für die Unterstützung von SFTP konfiguriert ist. Es kann SFTP-Sitzungen bedienen, indem ein externes Programm (mit dem Namen sftp-server) gestartet wird . In diesem Fall hätten Sie das gleiche Problem wie bei Programmen wie scp. Oder der Server kann eine SFTP-Sitzung über etwas ausführen , das als "internes SFTP" bezeichnet wird und für das kein Shell aufgerufen werden muss. Es hängt nur davon ab, wie der jeweilige SSH-Server konfiguriert ist.
Der Grund dafür ist sshd, dass die serverseitige Komponente Prozesse mithilfe Ihrer Shell aufruft. Wenn eine interaktive Shell erzeugt wird, wird sie als Anmeldeshell erzeugt. Andernfalls wird das -cArgument verwendet, um eine nicht interaktive Shell zu erzeugen und den von Ihnen angegebenen Befehl auszuführen.
Alle von Ihnen angegebenen Operationen (angegebene Befehle und scp) sind nicht interaktive Operationen, sodass Bash normalerweise nicht geladen .bashrcwird. Bash hat jedoch ein spezielles Gehäuse für den Aufruf von, sshdsodass es trotzdem aufgerufen wird . Wenn Sie zsh verwenden, wird .zshenv(das für alle Shells aufgerufen wird) geladen, aber .zshrc(das gilt nur für interaktive Shells) nur, wenn Sie speziell eine Shell-Sitzung laden.
In diesem Fall haben Sie kein Glück, wenn Sie Bash verwenden. Es gibt keine Möglichkeit, einen SSH-Befehl auf der Serverseite aufzurufen, ohne die Shell zu verwenden. Dies gilt auch für scp und sftp. In den meisten Fällen möchten Sie die Shell verwenden, da sie Dinge wie PATHfür verschiedene Programme einrichtet und eine angemessene Menge an Skripten für komplexe Befehle ermöglicht, sodass OpenSSH sie immer verwendet.
Dies hat auch einige Sicherheitsvorteile: Wenn Sie versuchen, sich bei einem Systemkonto anzumelden, das irgendwie ein gültiges Kennwort, aber eine Shell von /usr/sbin/nologinoder hat /bin/false, können Sie nichts tun, was wahrscheinlich der Systemadministrator beabsichtigt hat.
Es gibt Möglichkeiten, dies zu mildern. Viele Leute führen ein Git-Repository ihrer Punktedateien und entwickeln sie auf einem System und stellen sie dann für andere bereit. Zum Beispiel entwickle ich Dotfiles immer auf meinem Laptop. Vermutlich würden Sie dieses Problem etwas früher bemerken, wenn Sie ein neues Terminalfenster öffnen, wenn es sofort beendet wird, und Sie möglicherweise Root-Zugriff haben, um es selbst zu beheben.
Wenn Sie eine Konfiguration testen müssen, die Sie möglicherweise sperrt, z. B. eine Shell-Konfiguration oder eine sudoersÄnderung, können Sie eine Shell (normal bzw. root) offen lassen und dann einige Tests durchführen. Wenn Sie also etwas kaputt machen, haben Sie immer noch eine Weg hinein, um es rückgängig zu machen.