• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

SSH angepasste Regel für Benutzer mit IPV6

OP
S

Schnickischnacki

Newbie
Geier0815 schrieb:
@Schnickischnacki
Zwei Sachen: Das eth0 nur ein Beispiel war für dein tatsächliches Interface, ist dir hoffentlich bewußt. Zweitens vermute ich das es bei sshd ähnlich ist wie bei firewall-Regeln, sprich sobald der erste Match auftritt, steigt die Verarbeitung der Regeln aus. Wenn Du also "DenyUsers Admin" vor "AllowUsers Admin@" stehen hast, sollte die letztere niemals zur Anwendung kommen weil vorher schon das Deny festgestellt wurde.
Zum Vergrößern anklicken....
Dann darf ich gar keine <DenyUsers> Direktive festlegen?
Laut MANPAGE werden diese Direktiven wie folgt abgearbeitet, "DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups".
Also ist doch die Position/Reihenfolge dieser Direktiven in meiner Konfig egal?
 
Geier0815

Geier0815

Guru
Wenn dem so ist, dann solltest Du <DenyUsers> weg lassen. Da gilt dann wohl eher "was nicht erlaubt ist, ist verboten".
Wie gesagt vermute ich das er beim ersten Treffer aussteigt und das wäre in deinem Fall, egal ob Reihenfolge durchs Programm oder die Konfig, der Treffer auf "Admin" ohne weitere Angaben.
Aber wie schon im vorherigen Post geschrieben: Ist nur eine Vermutung meinerseits.
 
OP
S

Schnickischnacki

Newbie
Wie wäre das Folgende:
Code: 
AllowUsers ADMIN@192.168.178.* ADMIN@fe80::%eth0/64
AllowGroups Internet

Wobei die Gruppe <internet> eine manuell erstellte Gruppe ist. Zu dieser Gruppe gehören "junge", "frau" und "muckie".
 
OP
S

Schnickischnacki

Newbie
Gräfin Klara schrieb:
Für die Definition des Netzwerkes ist ListenAddress zuständig.
Der Server liest beim Start die ListenAddress und nimmt sich die CIDR aus der Netzwerkkonfiguration des devices.
Damit ist der Netzwerkbereich definiert. Für Einschränkungen innerhalb dieses Bereichs existiert "Match Address" und "Match User"
AllowUsers geht hier fehl.
Zum Vergrößern anklicken....
Da könnte Sie eventuell Recht haben. Zumindest konnte ich heute den Zugang für den Benutzer <ADMIN> nicht auf mein lokales Netzwerk beschränken. Wobei ich VPN nutze um eine Verbinung nach Außen und zurück zu meinem NAS aufzubauen.
 
Zuletzt bearbeitet:
OP
S

Schnickischnacki

Newbie
Habe es jetzt anders gelöst, über die <authorized_keys> Datei vom Benutzer ADMIN. Wie im folgenden ergänzt:
Code: 
from="192.168.0.0/24,fe80::%eth0/64" <your public key here>

Dafür lässt er mich jetzt aktuell nicht mehr mit dem ADMIN rein.

Hier meine LOG vom Verbindungs-Vorgang:
BENUTZER@PC:~/.ssh$ ssh ADMIN@NAS -i id_ed25519 -p 22 -vvv
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
debug1: Reading configuration data /etc/ssh/ssh_config
...
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/BENUTZER/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/BENUTZER/.ssh/known_hosts2'
debug2: resolving "NAS" port 22
debug3: resolve_host: lookup NAS:22
debug3: ssh_connect_direct: entering
debug1: Connecting to NAS [192.168.178.2] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file id_ed25519 type 3
debug1: identity file id_ed25519-cert type -1
...
debug1: Authenticating to NAS:22 as 'ADMIN'
debug3: put_host_port: [NAS]:22
debug3: record_hostkey: found key type ED25519 in file /home/BENUTZER/.ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file /home/BENUTZER/.ssh/known_hosts:2
debug3: load_hostkeys_file: loaded 2 keys from [NAS]:22
debug1: load_hostkeys: fopen /home/BENUTZER/.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
...
debug3: put_host_port: [192.168.178.2]:22
debug3: put_host_port: [NAS]:22
debug3: record_hostkey: found key type ED25519 in file /home/BENUTZER/.ssh/known_hosts:1
debug3: record_hostkey: found key type ECDSA in file /home/BENUTZER/.ssh/known_hosts:2
debug3: load_hostkeys_file: loaded 2 keys from [NAS]:22
debug1: load_hostkeys: fopen /home/BENUTZER/.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 '[NAS]:22' is known and matches the ED25519 host key.
debug1: Found key in /home/BENUTZER/.ssh/known_hosts:1
...
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: id_ed25519 ED25519 SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx explicit
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
ADMIN@NAS: Permission denied (publickey).
Zum Vergrößern anklicken....

Ich verbinde mich dabei über meinen Client. Es folgt die Ausgabe von <ifconfig>
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
...

wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.xxx netmask 255.255.255.0 broadcast 192.168.178.255
inet6 fe80::qqqq:wwww:eeee:rrrr prefixlen 64 scopeid 0x20<link>
inet6 2a00:qqqq:wwww:eeee:rrrr:tttt:zzzz:uuuu prefixlen 64 scopeid 0x0<global>
...
Zum Vergrößern anklicken....
 
OP
S

Schnickischnacki

Newbie
Weitere Fehlermeldungen auf meinem NAS:
Apr 04 23:20:04 NAS sh[1151]: [synorelayd] reloaded.
Apr 04 23:20:04 NAS systemd[1]: Started OpenBSD Secure Shell server.
Apr 04 23:20:49 NAS sshd[1334]: Authentication refused: bad ownership or modes for file /volume1/homes/ADMIN/.ssh/authorized_keys
Apr 04 23:20:49 NAS sshd[1334]: Connection closed by authenticating user ADMIN 192.168.178.9 port 40368 [preauth]
Apr 04 23:20:56 NAS sshd[1344]: Authentication refused: bad ownership or modes for file /volume1/homes/ADMIN/.ssh/authorized_keys
Apr 04 23:20:56 NAS sshd[1344]: Connection closed by authenticating user ADMIN 192.168.178.9 port 56072 [preauth]
Apr 04 23:21:25 NAS sshd[1385]: Authentication refused: bad ownership or modes for file /volume1/homes/ADMIN/.ssh/authorized_keys
Apr 04 23:21:25 NAS sshd[1385]: Connection closed by authenticating user ADMIN 192.168.178.9 port 57508 [preauth]
Apr 04 23:21:29 NAS sshd[1392]: Authentication refused: bad ownership or modes for file /volume1/homes/ADMIN/.ssh/authorized_keys
Apr 04 23:21:29 NAS sshd[1392]: Connection closed by authenticating user ADMIN 192.168.178.9 port 57514 [preauth]
Zum Vergrößern anklicken....
 
M

marce

Guru
Code: 
 Apr 04 23:21:29 NAS sshd[1392]: Authentication refused: bad ownership or modes for file /volume1/homes/ADMIN/.ssh/authorized_keys
ist ja recht eindeutig.
 
OP
S

Schnickischnacki

Newbie
Habe die Datei <authorized_keys> neu erstellt, mit Standard Berechtigungen unter Synology. Hat was gebracht, dafür bekomme ich jetzt eine andere Meldung:
Apr 05 07:47:25 NAS sshd[29070]: error: Refused by key options
Apr 05 07:47:25 NAS sshd[29070]: Connection closed by authenticating user ADMIN 192.168.178.9 port 53252 [preauth]
Apr 05 07:47:39 NAS sshd[29089]: /var/services/homes/ADMIN/.ssh/authorized_keys:1: Authentication tried for ADMIN with correct key but not from a perm...::%eth0/64).
Zum Vergrößern anklicken....

Meine <authorized_keys> sieht wie folgt aus:
from="192.168.178.0/16,fe80::%eth0/64" ssh-ed25519 SCHLÜüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüüSSEL ADMIN MASTER SSH@NAS
Zum Vergrößern anklicken....
Das "ADMIN MASTER SSH" stammt daher, dass ich unterschiedliche Schlüssel erstellt habe. Also einen MASTER Schlüssel, der Passwort verschlüsselt ist und etliche ohne Passwort. Mein ADMIN hat aktuell nur den Schlüssel mit Passwort. Es soll aber noch einer ohne Passwort dazu kommen.

Zum verbinden habe ich die folgenden Befehle genutzt auf meinem Laptop(VPN war deaktiviert):
BENUTZER@LAPTOP:~/.ssh$ ssh ADMIN@NAS -i id_ed25519 -p 22 -4
ADMIN@NAS: Permission denied (publickey).
BENUTZER@LAPTOP:~/.ssh$ ssh ADMIN@192.168.178.2 -i id_ed25519 -p 22 -4
ADMIN@192.168.178.2: Permission denied (publickey).
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
OP
S

Schnickischnacki

Newbie
Nochmal in Klartext. Auf meinem NAS erhalte ich die folgende Meldung:
/var/services/homes/ADMIN/.ssh/authorized_keys:1: Authentication tried for ADMIN with correct key but not from a permitted host (host=192.168.178.9, ip=192.168.178.9, required=192.168.178.0/16,fe80::%eth0/64)
Zum Vergrößern anklicken....
 
OP
S

Schnickischnacki

Newbie
Anscheinend kommt SSHD nicht mit der CIDR Schreibweise klar. Ein <192.168.178.0/24> akzeptiert er nicht, nur ein <192.168.178.*>. Und bei IPV6 weiß ich nicht wie ich es richtig testen kann. Also Speziell LINK-LOKAL.

Hat da Jemand einen Ansatz wie ich LLA testen kann?

Weiterhin vermute ich, dass er <::> (Doppel-Scope) nicht versteht. Nur <*> (Platzhalter).

Kann das Jemand bestätigen?
 
/dev/null

/dev/null

Moderator
Teammitglied
Liebe/r @Schnickischnacki

Trotz deiner drei Smileys bin ich mir nicht sicher, ob du die obigen zwei Bemerkungen ernst gemeint hast.
Ich hoffe mal, dass das nicht der Fall ist!

Denn:
  1. kannst du ganz sicher sein, dass wir uns alle noch mit IPv6 befassen werden, selbst ich hoffe, dass ich den Durchbruch von IPv6 noch erleben darf. Und
  2. ist deine Bemerkung mit dem trojanischen Pferd einfach nur dumm.

Noch eine letzte Bemerkung meinerseits zu dem im Titel stehenden Inhalt dieses Threads:
Wie ich dir schon einmal geschrieben habe, kann ich deine (garantiert gut gemeinte!) Vorgehensweise nicht verstehen. Ich freue mich aber wirklich, wenn ich lesen kann, dass sich jemand mit IPv6 befasst!
Aber, dass du versuchst, an Stelle eines bewährten Verfahrens, der Auth mit Public Keys, eine Einschränkung der berechtigten Benutzer durch Zulassen oder Sperrung dieser Benutzer zu erreichen, kann ich wirklich nicht verstehen. Hier sehe ich wirklich keinen Sinn darin.
Alle die durch mich administrierten Geräte laufen im vollständigen Dualstack-Betrieb. Selbst meinem WireGuard-VPN ist es völlig egal, ob der Tunnel über eine Verbindung mit IPv6 (Standard!) oder nur mit dem alten IPv4 aufgebaut wird. Intern sind eh beide Protokolle möglich. Und auch dem sshd ist es völlig egal, über welches Protokoll ich komme.

vy 73 de Peter
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben