
Ich bin als Root bei einem Linux-Server (Debian Stretch) angemeldet. Wenn ich den SSH-Client als Root ausführe, besteht der SSH-Client anscheinend darauf, /root/.ssh/
als Speicherort aller SSH-Konfigurations- und Schlüsseldateien zu verwenden, anstatt ~/.ssh
:
$ id
uid=0(root) gid=0(root) groups=0(root)
$ export HOME=/srv/scratch/user
$ cd ~/.ssh
$ pwd
/srv/scratch/user/.ssh
$ ssh -vvv [email protected]
OpenSSH_7.4p1 Debian-10+deb9u7, OpenSSL 1.0.2t 10 Sep 2019
debug1: Reading configuration data /root/.ssh/config
debug1: /root/.ssh/config line 3: Applying options for example.com
debug1: Reading configuration data /etc/ssh/ssh_config
... more lines that never mention /srv/scratch/user/.ssh ...
Warum verwendet der SSH-Client das .ssh
Verzeichnis in nicht /srv/scratch/user
?
Antwort1
export HOME=/srv/scratch/user
ssh
HOME
verwendet die Umgebungsvariable nicht, um das Home-Verzeichnis des Benutzers zu finden. Es ruftgetpwuid()
und verwendet das von diesem zurückgegebene Home-Verzeichnis. getpwuid()
Gibt die Benutzerinformationen von /etc/passwd
oder von wo auch immer Ihr bestimmtes System Benutzerinformationen speichert zurück.
Sie können ssh dazu bringen, eine andere Konfigurationsdatei zu lesen, indem Sie-F
Möglichkeit:
-Fconfigfile
Gibt eine alternative benutzerspezifische Konfigurationsdatei an. Wenn in der Befehlszeile eine Konfigurationsdatei angegeben wird, wird die systemweite Konfigurationsdatei (/etc/ssh/ssh_config) ignoriert. Der Standardwert für die benutzerspezifische Konfigurationsdatei ist ~/.ssh/config.
Sie können SSH-Schlüssel angeben mit-i
:
-ichidentity_file
Wählt eine Datei aus, aus der die Identität (privater Schlüssel) für die Authentifizierung mit öffentlichem Schlüssel gelesen wird. Der Standardwert ist ~/.ssh/id_dsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519 und ~/.ssh/id_rsa. Identitätsdateien können auch für jeden Host einzeln in der Konfigurationsdatei angegeben werden. Es sind mehrere -i-Optionen möglich (und mehrere Identitäten können in Konfigurationsdateien angegeben werden). Wenn keine Zertifikate explizit durch die CertificateFile-Direktive angegeben wurden, versucht ssh auch, Zertifikatsinformationen aus dem Dateinamen zu laden, der durch Anhängen von -cert.pub an die Identitätsdateinamen erhalten wird.
Beachten Sie Folgendes, wenn Sie einen Befehl mit „~“ ausführen, um einen Dateinamen anzugeben, etwa so:
ssh -F ~/some/config/file ...
dann wird das "~" von Ihrer Shell interpretiert, nicht von ssh.