SSHD wird in PATH nicht angezeigt, aber SSH?

296
aditya rawat

Ich arbeite derzeit an ssh-Protokoll in Python und ich habe eine Menge Zeit damit verschwendet, nur den openssh-Server zu starten. Danach konnte ich es normal starten und meine Python-Skripte ausführen. Für beide gab es keine Erlaubnisfrage.

Aber das Problem ist, wenn ich mache which ssh, gibt es den Speicherort des openssh-Clients (usr / bin / ssh). Aber wenn ich es versuche which sshd, gibt es nichts zurück, aber der Server funktioniert bis jetzt einwandfrei. Warum passiert das und wie kann ich das beheben?

0
Das scheint normal zu sein. `sudo which sshd` sollte etwas drucken. Nichts zu reparieren. Kamil Maciorowski vor 5 Jahren 0
@KamilMaciorowski ein "which sshd" funktioniert für mich als normaler Benutzer auf meiner Ubuntu 16.04- und CentOS 6-Box. Eine teilweise Problemumgehung (als root) könnte die Verwendung von find / -type f -executable -name "sshd" sein. davidgo vor 5 Jahren 0
@ KamilMaciorowski du hast recht. Es ist nichts zu befürchten. Wie von davidgo erwähnt, sollte es auch ohne Root-Privilegien funktionieren aditya rawat vor 5 Jahren 0
Nein, da der SSHD-Daemon zum Starten root sein muss, da er einen der "low" -Ports öffnet. Außerdem wird er normalerweise als Dienst verwendet. Sein genauer Standort ist nur in der Dienstdefinition relevant. xenoid vor 5 Jahren 0
@xenoid Danke für deine Hilfe. Es ist mir sehr klar. aditya rawat vor 5 Jahren 0

1 Antwort auf die Frage

2
Kamil Maciorowski

sshist normalerweise dazu gedacht, von irgendjemandem ausgeführt zu werden, sshdnicht von normalen Benutzern aufgerufen zu werden; daher ist der erstere (zB) in /usr/binund der letztere in /usr/sbin.

Nun, diese Pfade können variieren. Der Punkt ist das Verzeichnis der sshausführbaren Datei ist im normalen Benutzer PATH, aber das Verzeichnis der sshdausführbaren Datei ist normalerweise nicht (es sollte jedoch in root's' sein PATH).

Sie können Ihren (regulären Benutzer) PATHselbst ändern, aber das Hinzufügen /usr/sbinist nicht gut, da Sie entweder keine Dateien von dort ausführen können, oder Sie werden sie formal ausführen können, aber Sie werden dazu berechtigt sein Ausgaben später.

Nichts Besonderes daran, Sie sollten das System auf diese Weise nicht beschädigen können. Dies führt jedoch dazu, dass Ihre Befehlszeile (Tabulatorerweiterung) mit ausführbaren Dateien verstreut wird, die Sie nie als normaler Benutzer ausführen müssen.

Diese ausführbaren Dateien benötigen rootGründe. Aus sshdden Gründen sind:

  • Es ist als systemweiter Dienst konzipiert, als Daemon. zu starten, sobald das System startet, wenn noch keine Benutzer angemeldet sind; andere Benutzer in das System einlassen;
  • Oft öffnet sich ein "niedriger" Port, reguläre Benutzer sind dazu selten berechtigt.

which sshdgibt nichts für dich zurück, sudo which sshdsollte etwas zurückgeben. Das scheint normal zu sein. Es gibt nichts zu reparieren.

Nur dass sie von normalen Benutzern betrieben werden kann - es ist nicht ungewöhnlich, sie einfach auf Port 2222 zu starten davidgo vor 5 Jahren 0
@davidgo: '' *** Sie *** kann von normalen Benutzern betrieben werden ''? Ich hoffe das ist eine Autokorrektur. … Aber im Ernst - obwohl es wahr ist, dass ein normaler Benutzer einen Socket an Port # 2222 binden kann, was bringt es, einen sshd-Server unprivilegiert zu betreiben? Es kann nicht für andere Benutzer als Sie festgelegt werden, und es kann nicht einmal Ihr Kennwort überprüfen. Ich nehme an, es unterstützt das kennwortlose Anmelden als Sie selbst, aber was ist der Anwendungsfall? Scott vor 5 Jahren 0
Sag mir, ob ich das richtig verstanden habe. SSHD ist ein Daemon, dh ein systemweiter (Server-) Dienst, so dass es sehr sinnvoll ist, dass er im `root`-Pfad liegt, wohingegen ssh ein Benutzerservice (ein Client für SSH-Server) ist, auf den jeder zugreifen kann. aditya rawat vor 5 Jahren 0
@adityarawat Grundsätzlich ja. Es gibt mehr Tools wie diese. Dämonen oder nicht, es ist nicht wirklich wichtig; Was zählt ist, sie sind besonders für `root` nützlich, nicht für normale Benutzer. Kamil Maciorowski vor 5 Jahren 0