NEWS
Tester für WireGuard Adapter gesucht
-
root ist im Regelfall nicht von außen via ssh erreichbar.
Bei *buntu ist der nicht mal von innen aktiv. -
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
kannst du einfach eine Konsole (Linux=Terminal, Windows=cmd/Eingabeaufforderung) öffnen und
wie gesagt, das funktioniert leider nicht
ssh: connect to host 10.0.1.204 port 22: Connection timed out
liegt es event. an der Config?
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options override the # default value. Include /etc/ssh/sshd_config.d/*.conf #Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_ecdsa_key #HostKey /etc/ssh/ssh_host_ed25519_key # Ciphers and keying #RekeyLimit default none # Logging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin prohibit-password #StrictModes yes #MaxAuthTries 6 #MaxSessions 10 #PubkeyAuthentication yes # Expect .ssh/authorized_keys2 to be disregarded by default in future. #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 #AuthorizedPrincipalsFile none #AuthorizedKeysCommand none #AuthorizedKeysCommandUser nobody # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! #PasswordAuthentication yes #PermitEmptyPasswords no # Change to yes to enable challenge-response passwords (beware issues with # some PAM modules and threads) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
/pfad/zu/wg
danke Dir. Wie bekomme ich den Pfad raus ?
/pfad/zu/wg
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
Da musst du mal schauen welche Rechte erforderlich sind.
Ja - Ich nutze (genau wie Du) aus bequemlichkeit auch noch root.
Bei mir (Debian 11) liegtwg
unter /usr/bin und erfordert root:root.
Das muss ich jetzt auch mal ändern - habe da aber noch keinen Plan in der Tasche. da muss ich mich auch noch reinarbeiten. Am besten dürfte es wahrscheinlich sein das wg kommando in eine eigene Gruppe zu packen und das dann alles wasserdicht zu machen. Aber wg braucht halt aufgrund seiner Natur sehr hohe Rechte.@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
@grizzelbee
root ist im Regelfall nicht von außen via ssh erreichbar.
Bei *buntu ist der nicht mal von innen aktiv.Da kenne ich mich tatsächlich nicht mit aus. Ich bin debian-user.
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
@dslraser sagte in Tester für WireGuard Adapter gesucht:
Wie gebe ich denn einem User (ist schon angelegt) unter Debian11 die Rechte diese Kommandos auszuführen?
Da musst du mal schauen welche Rechte erforderlich sind.
which wg ls -la /pfad/zu/wg
das stet dann da bei wg
-rwxr-xr-x 1 root root 97376 Feb 25 2021 wg
-
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
Am besten dürfte es wahrscheinlich sein das wg kommando in eine eigene Gruppe zu packen und das dann alles wasserdicht zu machen.
Schau dir setuid an. Damit kann man erweiterte Rechte auch an einfache User weitergeben.
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
Schau dir setuid an. Damit kann man erweiterte Rechte auch an einfache User weitergeben.
Mache ich. Danke für den Tipp.
@Negalein
Ich habe mal schnell gegoogelt und habe das hier gefunden: https://linuxize.com/post/how-to-enable-ssh-on-ubuntu-20-04/
Dort steht, dass Ubuntu standartmäßig die Firewall ufw aktiv hat. Dort musst du den Zugriff über ssh noch zulassen:$ sudo ufw allow ssh
Schau bitte ggf. mal in den Artikel rein. Aber der timeout deutet schon stark auf die firewall hin.
-
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
Dort steht, dass Ubuntu standartmäßig die Firewall ufw aktiv hat.
Merci, das wars!!
Läuft und ist grün
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
Am besten dürfte es wahrscheinlich sein das wg kommando in eine eigene Gruppe zu packen und das dann alles wasserdicht zu machen.
Schau dir setuid an. Damit kann man erweiterte Rechte auch an einfache User weitergeben.
Ich habe mal für setuid Google bemüht und habe das hier gefunden und gemacht
chmod u+s /usr/bin/wg
Danach konnte ich mich als User im Adapter anmelden und es funktioniert. Das ist ein "sudo User". Ist damit alles okay, oder muss ich das anders machen, oder ist da jetzt was bedenklich was die Sicherheit angeht ?
-
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
Ja - Ich nutze (genau wie Du) aus bequemlichkeit auch noch root.
Ich nutze keinen root. Hab ich nicht genug Ahnung für.
-
@thomas-braun sagte in Tester für WireGuard Adapter gesucht:
Ich nutze keinen root.
Hab ich nicht genug Ahnung für.
oha, und das sagst gerade Du...
-
@Grizzelbee Sau geil, hat alles geklappt - Darauf haben viele gewartet
-
@dslraser sagte in Tester für WireGuard Adapter gesucht:
chmod u+s /usr/bin/wg
Danach konnte ich mich als User im Adapter anmelden und es funktioniert. Das ist ein "sudo User". Ist damit alles okay, oder muss ich das anders machen, oder ist da jetzt was bedenklich was die Sicherheit angeht ?
Soweit ich das verstehe darf damit jetzt jeder beliebige User
wg
ausführen. Das ist aus meiner Sicht für die Sicherheit von WireGuard etwas bedenklich, nicht aber für den ganzen Server. Denn das wg Kommando ist durchaus mächtig:~$ wg --help Usage: wg <cmd> [<args>] Available subcommands: show: Shows the current configuration and device information showconf: Shows the current configuration of a given WireGuard interface, for use with `setconf' set: Change the current configuration, add peers, remove peers, or change peers setconf: Applies a configuration file to a WireGuard interface addconf: Appends a configuration file to a WireGuard interface syncconf: Synchronizes a configuration file to a WireGuard interface genkey: Generates a new private key and writes it to stdout genpsk: Generates a new preshared key and writes it to stdout pubkey: Reads a private key from stdin and writes a public key to stdout You may pass `--help' to any of these subcommands to view usage.
Ich gebe aber zu, das ich weder in WireGuard (und dem wg Kommando) noch in Linux tief genug drin bin um wirklich die komplette Tragweite beurteilen zu können. Die Frage muss wahrscheinlich am ehesten lauten: Wird der aktuelle Sicherheitslevel des Servers dadurch gravierend beeinträchtigt? Ich persönlich empfinde es aber durchaus als Gewinn, das ich jetzt die Anzahl der Peers überwachen kann und überhaupt merke, wenn da plötzlich eins hinzu kommt.
-
@grizzelbee
ich habe es mal rückgängig gemacht und bin im Adapter nun erstmal wieder auf root.
(Ich hatte zum testen mal einen einfachen User angelegt, der durfte dann tatsächlich wg ausführen....) -
Hallo @dslraser,
cool, kannst Du bitte erklären, wie Du das in Iqontrol gemacht hast.
Danke. -
@dirk1962 sagte in Tester für WireGuard Adapter gesucht:
Hallo @dslraser,
cool, kannst Du bitte erklären, wie Du das in Iqontrol gemacht hast.
Danke.Hm, was soll ich da erklären ? Ich habe über den Adapter meine VPN User. Für diese habe ich mir dann jeweils einen alias gemacht und über Additional_Control in iQontrol eingebunden. (alias ist eigentlich auch nicht nötig, der Adapter bietet ja alle Datenpunkte)
-
Ich habe mir mal zu den Sicherheitsaspekten Gedanken gemacht und bin zu folgender Lösung gekommen: Über eine simple sudoers Regel kann man den Monitoring-Befehl für genau einen User freigeben ohne gleich die ganze wg-Executable für alle freigeben zu müssen, was bei setUid ja der Fall ist. Das halte ich, nach aktuellem Kenntnisstand, für den sichersten Weg.
Details zur Konfig habe ich mal in den ersten Post hier ganz oben und (etwas ausführlicher) in die readme geschrieben. -
@grizzelbee sagte in Tester für WireGuard Adapter gesucht:
visudo als adminstrativer User zum editieren der sudoers Datei aufrufen. Es wird dringend davon abgeraten sudoers auf einem anderen Wege zu editieren.
Am Ende der Datei folgende Zeile hinzufügen: <name-des-monitoring-users> ALL=NOPASSWD:/usr/bin/wg show all dump (<name-des-monitoring-users> muss natürlich durch euren User ersetzt werden unnd /usr/binggf durch einen anderen Pfad falls wg irgendwo anders bei euch liegt. )
Datei speichernNach Eingabe dieser Regel kann in der Konfig das Häkchen bei sudogesetzt werden.
Danke, läuft bei mir mit der sudo Config
-
Hallo @dslraser,
da habe ich wohl nicht genau genug gefragt.
Ich bekomme die Ansicht nicht so hin, wie Du sie hast. Bei mir sieht das ziemlich bescheiden aus.
Ich habe auch keine Idee, wo Du die interne IP her bekommst. Der WireGuard Adapter zeigt die nicht an.
Und wie Du in den Additional Controls die vier Geräte separat anzeigst, ist mir auch nicht klar.
Wäre super, wenn Du mir dabei helfen würdest. -
@dirk1962
hier geht es dann weiter
https://forum.iobroker.net/post/773459