In Bezug auf die dritte vorgeschlagene Strategie ist es useradd -o -u userXXXmir nicht vertraut, mehrere Benutzer als dieselbe Benutzer-ID auszuführen, außer die von @jlliagre empfohlenen Optionen zu prüfen. (Wenn Sie damit weitermachen, würde es mich interessieren, ob Sie den Beitrag bei auftretenden Problemen (oder Erfolgen) aktualisieren können ...)
Ich schätze, meine erste Beobachtung bezüglich der ersten Option "Der öffentliche SSH-Schlüssel eines jeden wird in ~ root / .ssh / authorized_keys2 abgelegt" ist, dass Sie absolut nie auf einem anderen System arbeiten werden;
- Dann müssen Sie zumindest zeitweise mit Benutzerkonten und arbeiten
sudo
Die zweite Beobachtung wäre, dass Sie, wenn Sie an Systemen arbeiten, die HIPAA, PCI-DSS-Konformität oder Dinge wie CAPP und EAL anstreben, die Probleme von sudo umgehen müssen, weil;
- Es ist ein Industriestandard , Nicht-Root-Einzelbenutzerkonten bereitzustellen, die überwacht, deaktiviert, abgelaufen usw. werden können, normalerweise unter Verwendung einer zentralen Benutzerdatenbank.
Damit; Verwenden von personalisierten Konten und Sudo
Es ist bedauerlich, dass fast alles, was Sie als Systemadministrator auf einem Remotecomputer tun müssen, erhöhte Berechtigungen erfordert. Es ist jedoch ärgerlich, dass die meisten SSH-basierten Tools und Dienstprogramme während Ihres Aufenthalts beschädigt werden sudo
Daher kann ich einige Tricks weitergeben, die ich benutze, um die von sudoIhnen erwähnten Unannehmlichkeiten zu umgehen. Das erste Problem besteht darin, dass PermitRootLogin=noSCP-Dateien zu einer Art PITA werden , wenn die Root-Anmeldung mit blockiert wird oder wenn Sie nicht über den Root-Schlüssel mit ssh verfügen.
Problem 1 : Sie möchten Dateien von der Remote-Seite scpen, benötigen jedoch Root-Zugriff. Sie können sich jedoch nicht direkt als Root bei der Remote-Box anmelden.
Langweilige Lösung : Kopieren Sie die Dateien in das Ausgangsverzeichnis, chown und scp down.
ssh userXXX@remotesystem, sudo su -Etc, cp /etc/somefileszu /home/userXXX/somefiles, chown -R userXXX /home/userXXX/somefileszu verwenden scp Dateien von Remote abzurufen.
Sehr langweilig.
Weniger langweilig Lösung : sftp unterstützt das -s sftp_serverFlag, daher können Sie wie folgt vorgehen (wenn Sie kennwortloses sudo in konfiguriert haben /etc/sudoers).
sftp -s '/usr/bin/sudo /usr/libexec/openssh/sftp-server' \
userXXX@remotehost:/etc/resolv.conf
(du kannst diesen hack-around auch mit sshfs benutzen, aber ich bin mir nicht sicher, ob er empfohlen wird ... ;-)
Wenn Sie keine Sudo-Rechte ohne Passwort haben oder die oben beschriebene Methode aus irgendeinem konfigurierten Grund nicht funktioniert, kann ich eine weitere, weniger langweilige Dateiübertragungsmethode für den Zugriff auf Remote-Root-Dateien vorschlagen.
Port Forward Ninja Methode :
Melden Sie sich beim Remote-Host an, aber geben Sie an, dass der Remote-Port 3022 (kann frei und nicht für Administratoren reserviert sein, dh> 1024) an Port 22 auf der lokalen Seite zurückgeleitet werden soll.
[localuser@localmachine ~]$ ssh userXXX@remotehost -R 3022:localhost:22
Last login: Mon May 21 05:46:07 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
Holen Sie sich Wurzel in der normalen Art und Weise ...
-bash-3.2$ sudo su -
[root@remotehost ~]#
Jetzt können Sie die Dateien in die andere Richtung scpen, ohne den langweiligen, langweiligen Schritt, eine Zwischenkopie der Dateien zu erstellen.
[root@remotehost ~]# scp -o NoHostAuthenticationForLocalhost=yes \
-P3022 /etc/resolv.conf localuser@localhost:~
localuser@localhost's password:
resolv.conf 100%
[root@remotehost ~]#
Problem 2: SSH-Agentenweiterleitung : Wenn Sie das Root-Profil laden, z. B. durch Angabe einer Login-Shell, werden die für die SSH-Agentenweiterleitung erforderlichen Umgebungsvariablen SSH_AUTH_SOCKzurückgesetzt, daher ist die SSH-Agentenweiterleitung unter "defekt" sudo su -.
Halbgebackene Antwort :
Alles , was richtig eine Root - Shell lädt, wird zu Recht die Umwelt zurückzusetzen, jedoch gibt es eine leichte Behelfslösung Ihr Lieblings Einsatz , wenn Sie beide root - Berechtigung und die Fähigkeit , müssen Sie den SSH - Agenten zu verwenden , ZUGLEICH
Dies führt zu einer Art Chimären-Profil, das eigentlich nicht verwendet werden sollte, da es ein übler Hack ist , aber nützlich ist, wenn Sie Dateien vom Remote-Host als Root auf einen anderen Remote-Host übertragen müssen.
Auf jeden Fall können Sie aktivieren, dass Ihr Benutzer seine ENV-Variablen beibehalten kann, indem Sie in sudoers Folgendes festlegen:
Defaults:userXXX !env_reset
Auf diese Weise können Sie böse hybride Anmeldeumgebungen wie diese erstellen.
Login wie gewohnt;
[localuser@localmachine ~]$ ssh userXXX@remotehost
Last login: Mon May 21 12:33:12 2012 from 123.123.123.123
------------------------------------------------------------------------
This is a private system; blah blah blah
------------------------------------------------------------------------
-bash-3.2$ env | grep SSH_AUTH
SSH_AUTH_SOCK=/tmp/ssh-qwO715/agent.1971
Erstellen Sie eine Bash-Shell, die ausgeführt wird /root/.profileund /root/.bashrc. aber bewahrtSSH_AUTH_SOCK
-bash-3.2$ sudo -E bash -l
Diese Shell hat also root- $PATHRechte und root (aber ein verschachteltes Home-Verzeichnis ...)
bash-3.2# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) context=user_u:system_r:unconfined_t
bash-3.2# echo $PATH
/usr/kerberos/sbin:/usr/local/sbin:/usr/sbin:/sbin:/home/xtrabm/xtrabackup-manager:/usr/kerberos/bin:/opt/admin/bin:/usr/local/bin:/bin:/usr/bin:/opt/mx/bin
Sie können diesen Aufruf jedoch verwenden, um Dinge zu erledigen, die Remote-Sudo-Root erfordern, aber auch den SSH-Agentenzugriff wie folgt;
bash-3.2# scp /root/.ssh/authorized_keys ssh-agent-user@some-other-remote-host:~
/root/.ssh/authorized_keys 100% 126 0.1KB/s 00:00
bash-3.2#
-oFlag auf deruseraddHandbuchseite an. Mit diesem Flag können mehrere Benutzer dieselbe Benutzer-ID verwenden.