• 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

S

Sauerland

Ultimate Guru
Jeder User muss einen Schlüssel erzeugen, der liegt dann normalerweise in ~/.ssh des jeweiligen Users.
Kopieren kann man mit ssh-copy-id, dafür darf aber das Passwort login auf dem Server noch nicht ausgeschaltet sein.

Du kannst den Schlüssel zusätzlich mit einem Passwort schützen, aber wenn du z.B. automatische Scripte oder backups per rsync machst ist es von Vorteil, kein Passwort zu benutzen.
 
OP
S

Schnickischnacki

Newbie
Schade. In Seahorse als auch übers Terminal kann ich zwischen den Schlüsseln, mit und ohne Passwort, nicht unterscheiden.

Die Schlüssel würde ich lieber per USB Stick kopieren.
 
Zuletzt bearbeitet:
OP
S

Schnickischnacki

Newbie
Mal eine andere Frage. Ich habe gestern die folgende SSH Regel aktiviert:
Code: 
Match User ADMIN
      AllowUsers ADMIN@192.168.0.0/16 ADMIN@fe80::/64

Trotzdem konnte ich mich mit dem Benutzer ADMIN über VPN mit meinem NAS verbinden.

root@NAS:/etc/ssh# who
ADMIN pts/0 2024-03-28 06:15 (2a00:xxxx:yyyy:zzzz:aaaa:bbbb:cccc:dddd)
Zum Vergrößern anklicken....
Hier steht meine IPV6 Adresse mit der ich zu meinem NAS verbunden bin, obwohl ich oben in der <sshd_config> nur lokale SUBNET's zulasse. Muss ich das verstehen?
 
M

marce

Guru
sshd neu gestartet?

Ansonsten: komplette Config posten, exakte Befehle posten, Logeinträge posten, ggf. Loglevel hochdrehen.
 
S

spoensche

Moderator
Teammitglied
Schnickischnacki schrieb:
Wobei diese, übers Internet, nur auf bestimmte Befehle zurückgreifen dürfen.
Zum Vergrößern anklicken....
Ernsthaft? Kannst du mir die Hintergründe dafür nennen? Ich bin Jahrzehnte dabei und für so was ist mir kein einziger Anwendungsfall über den Weg gelaufen.
Aus der Sicherheitsperspektive sträuben sich mir dabei die nicht vorhandenen Nackenhaare.

Schnickischnacki schrieb:
Hier steht meine IPV6 Adresse mit der ich zu meinem NAS verbunden bin, obwohl ich oben in der <sshd_config> nur lokale SUBNET's zulasse. Muss ich das verstehen?
Zum Vergrößern anklicken....
Benutzername ADMIN ist nicht der Gleiche Benutzername root.
 
OP
S

Schnickischnacki

Newbie
Code: 
iphers aes128-ctr,aes128-gcm@openssh.com,aes192-ctr,aes256-ctr,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
MACs hmac-sha2-256,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com,umac-128@openssh.com
#    $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.



#PubkeyAuthentication yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no


# Change to no to disable s/key passwords
ChallengeResponseAuthentication no



# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePam no

#AllowAgentForwarding yes
AllowTcpForwarding no

ChrootDirectory none


# override default of no subsystems
#Subsystem    sftp    /usr/libexec/sftp-server
Subsystem       sftp    internal-sftp -f DAEMON -u 000

# Example of overriding settings on a per-user basis
#Match User anoncvs
#    X11Forwarding no
#    AllowTcpForwarding no
#    PermitTTY no
#    ForceCommand cvs server
Match User root
    AllowTcpForwarding yes
Match User admin
    AllowTcpForwarding yes
Match User anonymous
    AllowTcpForwarding no
    GatewayPorts no
Match User ADMIN
      AllowUsers ADMIN@192.168.0.0/16 ADMIN@fe80::/64
 
Zuletzt bearbeitet:
S

Sauerland

Ultimate Guru
Schränke die User auf dem NAS ein, damit jeder nur das machen kann, was er auch darf.

Denn dafür ist ssh eigentlich nicht gemacht.

PS:
So viele User sollten per ssh ja auch nicht zugreifen können.

Ich hab 2 Server im bösen Internet, zu denen ich mich per ssh und key verbinde.
Dann läuft dort noch vpn sodass ich mich eigentlich über ssh und vpn verbinde.......
 
OP
S

Schnickischnacki

Newbie
Anscheinend mag mein SSH die obige Syntax von mir nicht. Also den Zusatz mit dem Subnetz. Die folgende Syntax führt zu einem nicht starten von SSHD:
Code: 
Match User ADMIN
      AllowUsers ADMIN@192.168.0.0/16 ADMIN@fe80::/64

Allerdings ohne Subnetz geht es, wie z.b das folgende:
Code: 
Match User ADMIN
      AllowUsers ADMIN@192.168.1.211 ADMIN@fe80::aaaa:bbbb:cccc:dddd

Wie muss ich das Subnetz angeben, dass SSHD es schluckt?
 
OP
S

Schnickischnacki

Newbie
Um genau zu sein. Die Angabe des Subnetz beim IPV4 mag er nicht. Beim IPV6 hat er es geschluckt. Korrektur. Irgendwie auch nicht.
 
Zuletzt bearbeitet:
OP
S

Schnickischnacki

Newbie
Hab es gefunden. Er will unbedingt * (STERNCHEN) haben. :geek:

Der folgende Code sollte gehen:
Code: 
AllowUsers ADMIN@192.168.178.* ADMIN@fe80::*:*:*:*
 
Gräfin Klara

Gräfin Klara

Hacker
1. Sehen wir uns dein IPv6 fe80::/64 Netzwerk an:
Ich schreibe es zwecks besserer Übersicht in expanded notation.
Dein Netz fe80:: mit der CIDR 64 ist gültig von
fe80:0000:0000:0000:0000:0000:0000:0000
bis
fe80:0000:0000:0000:ffff:ffff:ffff:ffff
das wären Adressen für
18446744073709551616
Rechner. Genug, um die ganze Welt mehrfach zu vernetzen.
Beispiel: fe80::/122 wären 64 Adressen. Möglicherweise kommt das der Wahrheit näher.

2. AllowUsers ist keine Kategorie von Match User
Match User ADMIN heißt, wenn ADMIN, dann darf er dieses, jenes oder eben nicht.
AllowUsers ist kein Teil davon

3, IPv6 mit CIDR braucht meines Wissens auch das Netzwerk device als Teil der Angabe.
z.B. fe80::%eno1/122

Abgesehen davon ...
dein Sicherheits-Bedürfnis in Ehren, aber deine Art der Umsetzung geht an der Realität vorbei.

Gruß
 
Geier0815

Geier0815

Guru
@Gräfin Klara ,
warum sollte es interessieren wie groß das Netz sein könnte? fe80::/64 ist die normale Schreibweise für link-local-unicast Adressen, was letztlich bedeutet: Jeder Rechner im lokalen Netz bis zum nächsten Router. Guckst Du hier Und das ist ja das was der TE möchte: Von jedem Rechner im lokalen Netz Zugang mit den Anmeldedaten.

@Schnickischnacki
rein aus Interesse: Wenn Du das ethernet-interface mit angibst auf dem gelauscht werden soll, klappt es dann auch ohne die Sterne? Also zB fe80::%eth0/64
 
Gräfin Klara

Gräfin Klara

Hacker
Geier0815 schrieb:
@Gräfin Klara ,
warum sollte es interessieren wie groß das Netz sein könnte? fe80::/64 ist die normale Schreibweise für link-local-unicast Adressen, was letztlich bedeutet: Jeder Rechner im lokalen Netz bis zum nächsten Router. Guckst Du hier Und das ist ja das was der TE möchte: Von jedem Rechner im lokalen Netz Zugang mit den Anmeldedaten.
Zum Vergrößern anklicken....
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.
 
OP
S

Schnickischnacki

Newbie
Gräfin Klara schrieb:
2. AllowUsers ist keine Kategorie von Match User
Match User ADMIN heißt, wenn ADMIN, dann darf er dieses, jenes oder eben nicht.
AllowUsers ist kein Teil davon
Zum Vergrößern anklicken....
Es folgt der Auszug aus der <man sshd_config>:
Match
Introduces a conditional block. If all of the criteria on the Match line are satisfied, the keywords on the following lines override those set in the global section of the config file, until either another Match line or the end of the file.
The arguments to Match are one or more criteria-pattern pairs. The available criteria are User, Group, Host, and Address. The match patterns may consist of single entries or comma-separated lists and may use the wildcard and negation operators described in the PATTERNS section of ssh_config(5).

The patterns in an Address criteria may additionally contain addresses to match in CIDR address/masklen format, e.g. ''192.0.2.0/24'' or ''3ffe:ffff::/32''. Note that the mask length provided must be consistent with the address - it is an error to specify a mask length that is too long for the address or one with bits set in this host portion of the address. For example, ''192.0.2.0/33'' and ''192.0.2.0/8'' respectively.

Only a subset of keywords may be used on the lines following a Match keyword. Available keywords are AllowAgentForwarding, AllowTcpForwarding, Banner, ChrootDirectory, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, KbdInteractiveAuthentication, KerberosAuthentication, KerberosUseKuserok, MaxAuthTries, MaxSessions, PubkeyAuthentication, AuthorizedKeysCommand, AuthorizedKeysCommandRunAs, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, RequiredAuthentications1, RequiredAuthentications2, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.
Zum Vergrößern anklicken....
Da <AllowUsers> nicht in der Liste von <Match> steht, lassen sie sich nicht kombinieren?

Aber <AllowUsers> bietet die Möglichkeit Benutzer und IP-Bereiche zu kombinieren wie aus der MANPAGE hervorgeht:
AllowUsers
This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. The allow/deny directives are processed in the following order: DenyUsers, AllowUsers, DenyGroups, and finally AllowGroups.
Zum Vergrößern anklicken....

Wie sollte es denn dann aussehen mit der AllowUsers Direktive?
Code: 
DenyUsers ADMIN
AllowUsers ADMIN@192.168.178.* ADMIN@fe80::%eth0/64
Ich will ja nur den ADMIN Zugang auf die lokalen Adressen begrenzen. Alle anderen Benutzer sollen uneingeschränkt sein.

Alle anderen Benutzer würden dadurch nicht eingeschränkt?
 
Zuletzt bearbeitet:
Geier0815

Geier0815

Guru
@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.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben