WireGuard -> wg0 existiert bereits

[mat6937]

No 1
ich möchte auf beiden Haupt-PCs, auf beiden läuft (noch) Windows 10, die SSH Verbindung zu WG-Server und WG-Client unabhängig von der VPN Verbindung konfigurieren, das ich beide von überall erreichen kann. Da werde ich mich ein wenig reinfuchsen...

BTW: Windows 10 hat einen ssh-Client, den Du dort in der powershell benutzen kannst (genau so wie mit Linux).
Zum testen/probieren kannst Du auch temporär eine ssh-Verbindung (mit password-authetication) via WG-Tunnel, von deinem Windows-PC zu deinem Linux-Server herstellen. Evtl. musst Du in der Windows-Firewall noch etwas freigeben/konfigurieren.

[uan]

No. 2 scheint erledigt.
Mailstore hat nen Web Access der wunderbar funktioniert. Bringt der Tunnel einfach mit.

[uan]

No 1
ich möchte auf beiden Haupt-PCs, auf beiden läuft (noch) Windows 10, die SSH Verbindung zu WG-Server und WG-Client unabhängig von der VPN Verbindung konfigurieren, das ich beide von überall erreichen kann. Da werde ich mich ein wenig reinfuchsen...

BTW: Windows 10 hat einen ssh-Client, den Du dort in der powershell benutzen kannst (genau so wie mit Linux).
Zum testen/probieren kannst Du auch temporär eine ssh-Verbindung (mit password-authetication) via WG-Tunnel, von deinem Windows-PC zu deinem Linux-Server herstellen. Evtl. musst Du in der Windows-Firewall noch etwas freigeben/konfigurieren.

Danke, das funktioniert bestens, WG-Server wie Client laufen headless, ich melde mich auch hier daheim über die Powershell und ssh auf den WG-Maschinen an. Über Putty gehe ich auf den WG-Server in der Praxis, damit ich unterschiedliche Erscheinungsbilder habe und weiss, auf welcher Maschine ich jeweils bin. Ich komme jetzt in der Praxis überall drauf, das ist schon toll.

Die Geschichte mit der Password-Authentication muss ich mir nochmal zu Gemüte führen. Wie ich die Schlüssel erstelle, weiß ich. Was mir nur noch nicht so ganz klar ist, sind die Verzeichnisse - respektive die Konfigurations-Dateien, in die die Schlüssel geschrieben werden müssen. Ob das alles ganz allgemein und global in ein Verzeichnis kommt, oder Userbezogen. Da muss ich mich einlesen, nochmal so eine Nummer wie mit dem YT-Tutorial, klicken hier, schreiben da, return dort und läuft - klappt meistens nicht.

[mat6937]

Wie ich die Schlüssel erstelle, weiß ich. Was mir nur noch nicht so ganz klar ist, sind die Verzeichnisse - respektive die Konfigurations-Dateien, in die die Schlüssel geschrieben werden müssen. Ob das alles ganz allgemein und global in ein Verzeichnis kommt, oder Userbezogen. Da muss ich mich einlesen, ...

Vielleicht mit der Anleitung von MS (... wenn es um Windows 10 als ssh-Client geht): https://learn.microsoft.com/en-us/windo ... management

[uan]

Tunnel steht auch heute noch - grandios.

Heute aus der Praxis Datensicherung gefahren - großartig.

Jetzt hat mich der Alltag erstmal wieder - und lange Arbeitstage.
Werde mich als nächstes mit der ssh Authentification beschäftigen.

[uan]

Ich glaube, ich brauche nochmal eure Hilfe...

Der Tunnel lief einwandfrei - bis Montag. Da hatten wir ein Problem mit dem Netzwerk, es gab einen Stromausfall - und ich hatte im Laden 3 Tage kein Internet. Telefon lief, Lt Telekom war auch alle up, aber ich hatte keinen Internetzugang.

Nach ner ganzen Menge Trallala, FB auf Werkseinstellungen zurück und neuem Einrichten und viel hin und her stellte sich heraus, das auch meine Netzwerkkarte im Rechner ausgefallen war.

Lange Rede kurzer Sinn, nachdem ich die Tunnelmaschine (WG-Server im Laden) wieder hochgefahren hatte, konnte ich dann daheim den Tunnel wieder mit nem Neustart

Code: Alles auswählen

wg-quick up wg0

wieder starten. Läuft auch soweit alles wieder - nur habe ich jetzt folgendes Problem:
Ich kann mich weder vom Laden aus lokal - noch über Putty von zuhause aus, auf dem WG-Server anmelden.
Nein - falsch - vom Laden aus komme ich mit mit meinem User (sudo Rechte) auf den Server drauf, aber kann mich mit

Code: Alles auswählen

su -

nicht mehr anmelden, dann kommt

Code: Alles auswählen

Permission denied (publickey)

Ich vermute, dass das mit meinem Versuchen, mich über ssh authentification anzumelden zusammenhängt und ich irgendwas zerschossen oder gelöscht hab oä.
Ich kann mit dem sudo-User die Systemdateien (ich hoffe alle) editieren.

Kann ich diese SSH Zugriffe wieder rückgängig machen, dass ich mich zumindest wieder anmelden kann?

In der normalen SystemGUI kann ich mich als root nicht anmelden, da will er nur den sudo - User. Aber da muss es doch ne einfache Möglichkeit geben, nicht über SSH wieder auf die Maschine zu kommen und das gerade zu biegen, oder?

[mat6937]

Nein - falsch - vom Laden aus komme ich mit mit meinem User (sudo Rechte) auf den Server drauf, aber kann mich mit

Code: Alles auswählen

su -

nicht mehr anmelden, dann kommt

Code: Alles auswählen

Permission denied (publickey)

Ich verstehe nicht was Du meinst. Hast Du auf dem Server einen user mit passwort und ein Passwort für root? Wenn ja warum willst Du sudo benutzen und wenn nein, warum willst du "su -" auf dem Server benutzen?
Poste mal wie Du zum Server verbunden hast? ssh via WG oder ssh via Internet?

[uan]

Über den Tunnel von daheim aus kann ich mich über ssh gar nicht anmelden, es kommt bei

Code: Alles auswählen

ssh <IP WG-Server -durch den Tunnel> 

Code: Alles auswählen

Permission denied (publickey).

Dieselbe Meldung bei

Code: Alles auswählen

ssh meinesubdomain.duckdns.org 

Code: Alles auswählen

Permission denied (publickey).

Das hat vor dem Zusammenbruch einwandfrei funktioniert - aber wahrscheinlich hab ich mit dem SSH - Authentication Key-Gebimmels zerschossen. Kann ich die Keys wieder entfernen, das ich wieder normal über SSH, ohne Keys draufkomme?

[mat6937]

Dieselbe Meldung bei

Code: Alles auswählen

ssh meinesubdomain.duckdns.org 

Code: Alles auswählen

Permission denied (publickey).

Das hat vor dem Zusammenbruch einwandfrei funktioniert - aber wahrscheinlich hab ich mit dem SSH - Authentication Key-Gebimmels zerschossen. Kann ich die Keys wieder entfernen, das ich wieder normal über SSH, ohne Keys draufkomme?

Wie ist die Ausgabe von:

Code: Alles auswählen

ssh -v meinesubdomain.duckdns.org
nc -zv meinesubdomain.duckdns.org 22

? Wenn Du "passwort authetication" in der sshd_config deaktiviert hast, müsste das auch geändert werden. Hast Du eine config für den ssh-Client?

EDIT:

Kann es evtl. sein, dass die Portweiterleitungen in der FritzBox (für WG und ssh) nicht richtig konfiguriert sind?

[uan]

... Wenn Du "passwort authetication" in der sshd_config deaktiviert hast, müsste das auch geändert werden. Hast Du eine config für den ssh-Client?

...

Das muss ich morgen im Laden nachgucken...

...
Kann es evtl. sein, dass die Portweiterleitungen in der FritzBox (für WG und ssh) nicht richtig konfiguriert sind?

Beide WG-Maschinen haben zwei Weiterleitungen, SSH und Wireguard und dazu ne statische Route jeweils für das gegenüberliegende Netzwerk durch den Tunnel.

[uan]

Code: Alles auswählen

ssh -v meinesubdomain.duckdns.org

Code: Alles auswählen

OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to meinesubdomain.duckdns.org [zugeordneteIP] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: identity file /root/.ssh/id_ecdsa_sk type -1
debug1: identity file /root/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: identity file /root/.ssh/id_ed25519_sk type -1
debug1: identity file /root/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /root/.ssh/id_xmss type -1
debug1: identity file /root/.ssh/id_xmss-cert type -1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u2
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.2p1 Debian-2+deb12u2
debug1: compat_banner: match: OpenSSH_9.2p1 Debian-2+deb12u2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to meinesubdomain.duckdns.org:22 as 'root'
debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:hierstehteinschlüssel
debug1: load_hostkeys: fopen /root/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host 'meinesubdomain.duckdns.org' is known and matches the ED25519 host key.
debug1: Found key in /root/.ssh/known_hosts:4
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ecdsa_sk
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_ed25519_sk
debug1: Will attempt key: /root/.ssh/id_xmss
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com,ssh-dss,ssh-rsa,rsa-sha2-256,rsa-sha2-512>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ecdsa_sk
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Trying private key: /root/.ssh/id_ed25519_sk
debug1: Trying private key: /root/.ssh/id_xmss
debug1: Trying private key: /root/.ssh/id_dsa
debug1: No more authentication methods to try.
root@meinesubdomain.duckdns.org: Permission denied (publickey).

Code: Alles auswählen

nc -zv meinesubdomain.duckdns.org 22

liefert

Code: Alles auswählen

DNS fwd/rev mismatch: meinesubdomain.duckdns.org != port-<dieaktuelleip>.dynamic.as20676.net
meinesubdomain.duckdns.org [<dieaktuelleip>] 22 (ssh) open

[mat6937]

Code: Alles auswählen

nc -zv meinesubdomain.duckdns.org 22

liefert

Code: Alles auswählen

DNS fwd/rev mismatch: meinesubdomain.duckdns.org != port-<dieaktuelleip>.dynamic.as20676.net
meinesubdomain.duckdns.org [<dieaktuelleip>] 22 (ssh) open

Hast Du jetzt zusätzlich zur publickey-authentication auch die passwort-authentication aktiviert? Wenn ja, dann damit testen.

[uan]

ich bin jetzt im laden und komme gar nicht mehr drauf. weder von draussen über die ip noch vor ort im lokalen Netz über ssh.

kann das sein, dass ich mir das jetzt alles zerschossen hab?

Bleibt dann nur noch, dass ich mich direkt an der Maschine anmelden muss, also über die Debian Gui? Aber da lässt er keinen Root-Login zu...

Muss ich schon wieder neu einrichten?

[MSfree]

Bleibt dann nur noch, dass ich mich direkt an der Maschine anmelden muss, also über die Debian Gui? Aber da lässt er keinen Root-Login zu...

Dann logge dich als normaler Benutzer ein, starte ein Terminalfenster und gebe dort

Code: Alles auswählen

su -

ein. Schon bist du root.

Alternativ kannst du beim graphischen Login auch einfach ALT-STRG-F2 drücken und dich dann als root in der Textkonsole einloggen.

Muss ich schon wieder neu einrichten?

Ich kenne ein paar Methoden, mit denen man das Dateisystem soweit schrotten kann, daß eine Reperatur viel zu aufwändig wird, aber eine kleine Netzwerkmißkonfiguration ist definitiv kein Grund für eine Neuinstallation.

[uan]

Code: Alles auswählen

su -

funktioniert leider nicht, kommt immer Fehler bei der Authentifizierung (auf der Textkonsole)

Kann ich diesen SSH Key Kram wieder rückgängig machen?

EDIT:

Als normaler User mit sudo-Rechten komme ich auf der Textkonsole rauf

EDIT2:

Nachdem ich die ssh_conf und sshd_conf quasi "leergemacht" habe (alles auskommentiert) komme ich zumindest als normaler User mit sudo Rechten wieder direkt aus dem lokalen Netz über ssh, von draußen über die dyndns drauf.

[mat6937]

Code: Alles auswählen

su -

funktioniert leider nicht, kommt immer Fehler bei der Authentifizierung (auf der Textkonsole)

Kann ich diesen SSH Key Kram wieder rückgängig machen?

EDIT:

Als normaler User mit sudo-Rechten komme ich auf der Textkonsole rauf

Wie bist Du auf die Textconsole gekommen?
Der Wechsel vom normalen user zu root mit "su -" hat i. d. R. nichts mit den ssh-keys zu tun.

EDIT2:

Nachdem ich die ssh_conf und sshd_conf quasi "leergemacht" habe (alles auskommentiert) komme ich zumindest als normaler User mit sudo Rechten wieder direkt aus dem lokalen Netz über ssh, von draußen über die dyndns drauf.

Warum benutzt Du wenn es um ssh geht, den "normalen user mit sudo-Rechten"? Oder verstehe ich das falsch? Was genau meinst Du mit "als normaler User mit sudo Rechten wieder direkt aus dem lokalen Netz über ssh"?

Code: Alles auswählen

PermitRootLogin no

, oder?

[uan]

Ich war im Laden, Tastatur und Monitor angeklemmt und dann mit STRG+ALT+F2 auf die Textkonsole und dort mit dem normalen User (Uan) angemeldet, welcher sudo Rechte hat.
Damit kann ich arbeiten - vor Ort - komme aber nicht als Root drauf.

Im Moment steht der Tunnel wieder, ich kann arbeiten.

[mat6937]

Damit kann ich arbeiten - vor Ort - komme aber nicht als Root drauf.

Im Moment steht der Tunnel wieder, ich kann arbeiten.

D. h. Du hast dich bei der Installation "gegen root" und "für sudo" entschieden, oder? OK, das kann man so machen.