sshd.service oder ssh.service?

[michaa7]

Ich bin dabei einen neuen (gebrauchten) Rechner einzurichten und eine ssh Verbindung zum alten herzustellen.Das führt mich auch dazu den ssh server zu aktivieren.

Dieses posting (EN) verwirrt mich so sehr dass ich nicht weiß welche Variante ich wählen soll:

Code: Alles auswählen

systemctl enable ssh.service

Code: Alles auswählen

systemctl enable sshd.service

Mit einer der beiden Varianten schieße ich mir auf lange Sicht (wenn ich das dann vergessen habe) in den Fuss. Aber ich bin jetzt so verwirrt dass ich nicht erkenne welche die übergreifende oder die default Variante ist?

[heisenberg]

Na dann schau doch mal nach...

Code: Alles auswählen

systemctl list-units 'ssh*'

[JTH]

Ein kurzer Blick in die letzten Zeilen von

Code: Alles auswählen

systemctl cat ssh.service

mag auch weiterhelfen.

[cosinus]

Ist das nicht egal was man tipp?

Code: Alles auswählen

systemctl enable sshd

und

Code: Alles auswählen

systemctl enable ssh

führen zum gleichen Ergebnis. Oder nicht?

[JTH]

Ist das nicht egal was man tipp?

Vielleicht kommst du auch zur Antwort, wenn du die vorigen beiden Hinweise nachverfolgst …

[cosinus]

Vielleicht kommst du auch zur Antwort, wenn du die vorigen beiden Hinweise nachverfolgst …

Hab deinen Post da noch nicht gesehen und mich währenddessen selbst an meinem MATE-Terminal vergewissert

[michaa7]

Habt ihr das verlinkte posting denn gelesen?

Egal jetzt, ich habe jetzt das problen, das nach "systemctl enable ssh.service" der server inactiv bleibt.

# systemctl enable ssh.service
Synchronizing state of ssh.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable ssh

# service ssh status
○ ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: enabled)
Active: inactive (dead)
Docs: man:sshd(8)
man:sshd_config(5)

Ich verstehe auch die Config nicht die identisch zu der meines lapptops ist wo das alles funktioniert (/etc/ssh/sshd_config). Ich kann mich noch düster erinnern dass ich root zugrif verboten habe, und das ist auch so, aber davon steht in dieser config gar ncihts. Gibt es denn noch eine weitere (ausser /etc/ssh/sshd_config.d/*.conf welche es nicht gibt)???

Ich bin jetzt noch mehr verwirrt als zuvor ...

[michaa7]

Ein kurzer Blick in die letzten Zeilen von

Code: Alles auswählen

systemctl cat ssh.service

mag auch weiterhelfen.

DAS ist ja was mich verwirrt, DESWEGEN habe ich das posting ja überhaupt geschrieben, aber ist (S.o.) jetzt egal ...
.

[cosinus]

Habt ihr das verlinkte posting denn gelesen?

Egal jetzt, ich habe jetzt das problen, das nach "systemctl enable ssh.service" der server inactiv bleibt.

Ja, ich habe das gelesen.
Mit systemctl enable aktivierst du den Dienst bloß. Er startet dann beim nächsten reboot automatisch. Wenn er aber gestoppt ist, startet ihn das nicht. Du musst ihn also noch starten - oder das System rebooten

Code: Alles auswählen

systemctl start ssh

[michaa7]

OMG, danke, es gibt so viele Arten sich selbst im Weg zu stehn, ich finde immer eine.

Ja, klappt jetzt (wg. reboot)

Dennoch zum Abschluß die Frage: Wo ist/wird definiert, dass man das Einloggen als root verbietet?

[cosinus]

Dennoch zum Abschluß die Frage: Wo ist/wird definiert, dass man das Einloggen als root verbietet?

Über SSH? Ist standardmäßig schon verboten, also per Passwort.
Schau mal nach in der /etc/ssh/sshd_config
Such dir was aus:

Code: Alles auswählen

PermitRootLogin yes
PermitRootLogin no
PermitRootLogin without-password

[heisenberg]

Mit systemctl enable aktivierst du den Dienst bloß. Er startet dann beim nächsten reboot automatisch. Wenn er aber gestoppt ist, startet ihn das nicht. Du musst ihn also noch starten - oder das System rebooten

Code: Alles auswählen

systemctl start ssh

bzw. aktivieren und starten gleichzeitig:

Code: Alles auswählen

systemctl enable --now ssh

[michaa7]

...

Code: Alles auswählen

PermitRootLogin yes
PermitRootLogin no
PermitRootLogin without-password

Daran erinnere ich mich von früher. Aber das gibt es so nicht mehr in meiner sshd_config.

Was ich nun gefunden habe ist "#PermitRootLogin prohibit-password", was immer hier wieauchimmer funktionieren soll. ??? Bedeutet das dass es als root, wenn überhaupt dann nur per schlüssel oder irgendwas anderes als PW geht?

Wenn heutezutage root login per default verboten ist dann ist es ja ok, nur früher war es übersichtlicher.

Danke.

[cosinus]

Ok, es kann auch prohibit-password heißen...welches Debian genau läuft denn da?
prohibit-password und without-password müssten äquivalent sein. Mach einfach aus dem prohibit-password ein no und schon darf root sich nicht mehr einloggen über ssh, auch mit einem rsakey nicht. Nach der Änderung unebdingt den Dienst neu starten oder reloaden.

[michaa7]

debian/sid(uction)

Nur was ist denn jetzt die default Einstellung? Ich habe es testweise versucht und bekomme diese verwirrende Meldung. Wenn es per default NICHT funktionieren sollte würde ich mir eine andere als diese Meldung vorstellen:

# ssh root@neutower
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:6
remove with:
ssh-keygen -f "/root/.ssh/known_hosts" -R "neutower"
Host key for neutower has changed and you have requested strict checking.
Host key verification failed.

[cosinus]

Dann steckt in deiner ~/.ssh/known_hosts noch ein alter Key. Hast dich wohl mal mit einem anderen Rechner verbunden, der diesen hostname hatte. Mit PermitRootLogin hat das nichts zu tun. Hau den alten Schlüssel/Fingerprint weg, steht da ja auch:

Code: Alles auswählen

ssh-keygen -f "/root/.ssh/known_hosts" -R "neutower"

[michaa7]

Nee, das *ist* der Rechner mit dem ich mich verbunden habe, also der auf dem ich eben mit deiner Hilfe den ssh.service gestartet habe. Und wenn per default root login verboten wäre, dann sollte da gar nicht erst nach einem Schlüssel gesucht werden ... oder verstehe ich da etwas falsch?


Moooooment!

Ich versuche mich *auf eine andere Installation auf dem Gleichen Rechner ein zu loggen, sorry, mein Fehler. Gleiche IP, andere Installation. Gibt es da einen ausweg ohne ständig key löschen zu müssen?

(aber auch dann sollte diese Meldung nicht kommen, wenn ich mich als root einzuloggen versuche. Dass sie bei einem User kommt ist klar, jetzt.)

[cosinus]

Ich versuche mich *auf eine andere Installation auf dem Gleichen Rechner ein zu loggen, sorry, mein Fehler. Gleiche IP, andere Installation. Gibt es da einen ausweg ohne ständig key löschen zu müssen?

Das passiert nur wenn ssh bei dir merkt, dass sich der Key geändert hat, zB weil du dich mit dem selben Rechner (hostname) verbinden willst, der aber in der Zwischenzeit komplett neu installiert wurde. Dann ändert sich auch logischerweise der ssh fingerprint. Dann gibt es halt die Meldung, dass eine MITM-Attacke möglich sein kann.

Ich würde es so lassen, das passiert doch recht selten oder nicht?
Und den key hast du mit dem o.g. Befehl, der in der Meldung dann ja auch nochmal extra auftaucht, schnell entfernt.

(aber auch dann sollte diese Meldung nicht kommen, wenn ich mich als root einzuloggen versuche. Dass sie bei einem User kommt ist klar, jetzt.)

Wie gesagt das har nichts mit PermitRootLogin zu tun. Da liegt alles an der Datei in .ssh/known_hosts.

[JTH]

Habt ihr das verlinkte posting denn gelesen?

Ich glaube, du hattest den Link vergessen, oder hab ich ihn übersehen?

Aber ist wohl jetzt egal

[cosinus]

Hat er echt verlinktes Posting geschrieben? Ich dachte er meinte sein eigenes Posting. Mhhh...

[michaa7]

Habt ihr das verlinkte posting denn gelesen?

Ich glaube, du hattest den Link vergessen, oder hab ich ihn übersehen?

Aber ist wohl jetzt egal

Vergessen hier isser (oben auch)


Und jetzt kann ich mir die Frage auch selber beantworten: ssh.service ist die übergreifende Variante, der alias sshd.service ist dem untergeordnet. Das mag sich zwar aus dem Begriff "alias" ergeben, aber ob das zwingend so ist, da bin ich mir auch jetzt nicht sicher. Im gegebenen Fall sollte die Kausalkette den Zusammenhang klären, ich war aber gestern nicht in der Lage ihrer Logik zu folgen.

[KBDCALLS]

Ein kurzer Blick in die letzten Zeilen von

Code: Alles auswählen

systemctl cat ssh.service

mag auch weiterhelfen.

Und macht man gleiche mit sshd.service . Ist beides identisch. diff spukt nix aus.

[JTH]

Und macht man gleiche mit sshd.service . Ist beides identisch. diff spukt nix aus.

Richtig, das sollte dabei herauskommen

Um die Lösung dann nochmal für alle festzuhalten:
Eine Datei sshd.service gibt es gar nicht unter /lib/systemd/system. Die Datei ssh.service enthält aber die Zeile

Code: Alles auswählen

Alias=sshd.service

Man den SSH-Server also beliebig¹ unter den zwei Namen ansprechen – es macht keinen Unterschied. Das ist die Antwort auf die Eingangsfrage.


¹ Zumindest solange der Alias nicht entfernt wird.

[michaa7]

...Das ist die Antwort auf die Eingangsfrage.

Nein. Bist du meinem Link gefolgt und hast gelesen was dort steht? Jezzz isser da!

Naja, gut, weil ich ihn vergesssen habe, hier als michaa7.service:

Frage:

$sudo systemctl disable sshd.service
That seems to work. However, I can no longer enable the service at boot after that:

Antwort:

sshd service is originally written as ssh.service and sshd.service is set as alias name. Check out the last line of following output.

arryph@localhost:~$ systemctl cat sshd.service
# /lib/systemd/system/ssh.service
[Unit]
Description=OpenBSD Secure Shell server

...

[Install]
WantedBy=multi-user.target
Alias=sshd.service

Because of this, when ssh.service is enabled, we can refer it as sshd.service. But when you disabled sshd.service and rebooted, ssh.service is no longer loaded and because of this you can't refer it as sshd.service in that condition. You have to refer is as ssh.service instead. so if you run sudo systemctl enable ssh.service, it will enable ssh.service (aliased as sshd.service) successfully.

[JTH]

...Das ist die Antwort auf die Eingangsfrage.

Nein. Bist du meinem Link gefolgt und hast gelesen was dort steht? Jezzz isser da!

Ähmmm, ja, natürlich

Nee, offensichtlich nicht. Danke für die Korrektur. Tatsache, die Aliase gelten erst, nachdem ein Service enabled wurde. Ich war mir sicher, sie gälten immer. Aber das ist sinnvoll so wie es ist – der Alias wird ja im [Install]-Abschnitt angegeben, der eben nur für ein systemctl enable relevant ist.

Wieder was gelernt. Danke für das Thema hier