On Tue, May 19, 2015 at 12:35:57PM +0200, Miro Borik wrote:
* Stephan von Krawczynski (skraw@ithnet.com), [19.May 2015, 12:04] *
On Tue, 19 May 2015 11:35:31 +0200 "Dr. Werner Fink"
wrote: Wir reden hier von upstream von openssh und das sind wahrlich keine Script-Kiddies. Und was hat das mit Nullen zu tun? Der tcpwrapper ist uralt und wird schon lange nicht mehr gepflegt. Etwas mehr Flexibilität hilft hier sicher weiter.
Das erwähnte Match-Tag ist seit Jahren in der Manual-Page sshd_config(5) genaustens beschrieben:
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, LocalAddress, LocalPort, 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 AcceptEnv, AllowAgentForwarding, AllowGroups, AllowTcpForwarding, AllowUsers, AuthorizedKeysFile, AuthorizedPrincipalsFile, Banner, ChrootDirectory, DenyGroups, DenyUsers, ForceCommand, GatewayPorts, GSSAPIAuthentication, HostbasedAuthentication, HostbasedUsesNameFromPacketOnly, KbdInteractiveAuthentication, KerberosAuthentication, MaxAuthTries, MaxSessions, PasswordAuthentication, PermitEmptyPasswords, PermitOpen, PermitRootLogin, PermitTunnel, PubkeyAuthentication, RhostsRSAAuthentication, RSAAuthentication, X11DisplayOffset, X11Forwarding and X11UseLocalHost.
Es geht nicht um die Frage wie lange es irgendeine Option im sshd gibt. Es geht fundamental um die Frage ueber wieviele Orte im gesamten Dateisystem die sicherheitsrelevanten Einstellungen verteilt sind. Wenn ich 20 services habe die alle mit tcp wrapper laufen habe ich genau ein File mit 20 Eintraegen wo alle Zugriffsmoeglichkeiten geregelt sind. Wenn ich den hier praesentierten Weg gehe habe ich 20 Configfiles an zwanzig Orten mit mindestens 20 voellig verschiedenen Option-Keywords und nachfolgenden weiteren Optionen. Wem nicht einleuchtet dass das nicht der richtige Weg sein kann, dem ist echt nicht mehr zu helfen. Machen wir doch einfach den Test, schreib doch mal was in der jetzigen sshd-config notwendig ist um 20 IP-Adressen auf den sshd Port zu lassen und sonst keine. Im hosts.allow ist das genau eine Zeile. Zeig mir das jetzt mit "match":
Das ist opensource, eventuell hilft es, einen (netten) request upstream zu versuchen. Oder ein Fork von openssh zu machen oder eben in den sauren Apfel zu beißen. Ersteres beinhaltet natürlich Pflege, falls mal ein Security-Problem auftaucht.
Hallo,
genau. Was mache ich jetzt damit?
sshd: .... : spawn (echo -e "%u@%h[%a] on `/bin/date`" to %d connected me | /bin/mail -s "hosts.allow entry XYZ" root) & : ALLOW
Firewall Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr