Dear Maintainer,
I have /etc/security/access-sshd.conf with:
"
# Ansible managed

# Grant access via SSH to root account from the Ansible Controller hosts
+:root:<controller IP>

# Grant access via SSH to root account on the same DNS domain
+:root:.<my domain>

# Deny access to root account via SSH from anywhere else
-:root:ALL

# Grant access via SSH to members of UNIX groups defined on this host
+:(admins) (sshusers) (sftponly):ALL

# Grant access via SSH to users on the same DNS domain. The SSH server
# needs to have UseDNS option enabled for this rule to work correctly.
+:ALL:.<my domain>

# Deny access via SSH by anyone from anywhere
-:ALL:ALL
"
with <my domain> being my LAN DNS domain.

and /etc/pam.d/sshd
with
account  required     pam_access.so nodefgroup accessfile=/etc/security/access-sshd.conf


Since the pam upgrade from 1.5.3.7+b1 to 1.7.0 in testing around
February 2025 I am unable to login with these rules on boxes which have
an avahi 'local' domain assigned.

It seems pam in 1.7 resolve the 'local' avahi domain before the LAN DNS
domain assigned to the box.


from a box with a single interface I now get:
avril 14 02:42:52 cyclope sshd-session[31318]: pam_access(sshd:account): access denied for user `prahal' from `hermes.local'
avril 14 02:42:52 cyclope sshd-session[31318]: fatal: Access denied for user prahal by PAM account configuration [preauth]
and am denied access with:
Connection closed by 192.168.10.135 port 22


from a box with two interfaces to the same network (ie the second being
the ethernet inteface from this laptop dock at desk):
avril 14 03:07:33 hermes sshd-session[3411435]: Address 192.168.10.12 maps to cyclope.local, but this does not map back to the address.
avril 14 03:07:33 hermes sshd-session[3411435]: pam_access(sshd:account): access denied for user `prahal' from `192.168.10.12'
avril 14 03:07:33 hermes sshd-session[3411435]: fatal: Access denied for user prahal by PAM account configuration [preauth]
(this as I have two interfaces on cyclope plugged to the same network - wifi always on and ethernet from the dock when at desk, thus cyclope.local maps to 192.168.10.135 the )
and am denied access with:
Connection closed by 192.168.10.123 port 22


If I add to /etc/security/access-sshd.conf
+:ALL:.local
before the deny all:
-:ALL:ALL
I can now ssh to the boxes.


Is this change in domain resolution a regression or a fix ?


Various settings:

$ resolvectl
Global
         Protocols: +LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enp2s0)
    Current Scopes: none
         Protocols: -DefaultRoute +LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 3 (bridge0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: +DefaultRoute +LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: fc00:10::1
       DNS Servers: 192.168.11.1 192.168.10.1 fc00:10::1
        DNS Domain: prahal.homelinux.net
     Default Route: yes

Link 4 (docker0)
    Current Scopes: LLMNR/IPv4 LLMNR/IPv6 mDNS/IPv4 mDNS/IPv6
         Protocols: -DefaultRoute +LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no

Link 7 (veth05166a2)
    Current Scopes: LLMNR/IPv6 mDNS/IPv6
         Protocols: -DefaultRoute +LLMNR mDNS=resolve -DNSOverTLS DNSSEC=no/unsupported
     Default Route: no


on both boxes
cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search prahal.homelinux.net



on both boxes
grep UseDNS /etc/ssh/sshd_config
UseDNS yes


on both boxes
cat /etc/avahi/avahi-daemon.conf
# Ansible managed

# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=foo
#domain-name=local

# What domains we browse

use-ipv4=yes
use-ipv6=yes

# What interfaces we use

#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no

add-service-cookie=yes

#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
enable-reflector=no

#reflect-ipv=no

[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=768
rlimit-stack=4194304
rlimit-nproc=3






hostname -f
hermes.prahal.homelinux.net


hostname -f
cyclope.prahal.homelinux.net



on both boxes:
cat /etc/nsswitch.conf
# Ansible managed

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat systemd winbind
group:          compat systemd winbind
shadow:         compat
gshadow:        files

hosts:          files mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis



My setup is pretty rare, though as it might affect other and it might be
a regression I prefer to raise the issue.

I believe adding the 'local' domain to the access rules is correct, but
I don't know why pam_access reolves '<host>.local' first when all other
tools reolves <host>.<mydomain> first.

I have on local peculiarity is I have uncommented the prefer IPv4 in
/etc/gai.conf on all my boxes:
#
#    For sites which prefer IPv4 connections change the last line to
#
precedence ::ffff:0:0/96  100



Cheers,
Alban

On Mon, 14 Apr 2025 03:47:36 +0200 Alban Browaeys <prahal@yahoo.com> wrote:
(...)
have
DNS

Well probably because:

from hermes, requesting it own interface IP rDNS
$ host 192.168.10.123
123.10.168.192.in-addr.arpa domain name pointer hermes.prahal.homelinux.net.
123.10.168.192.in-addr.arpa domain name pointer hermes.
$ dig -x  192.168.10.123

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.123
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20228
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;123.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
123.10.168.192.in-addr.arpa. 0	IN	PTR	hermes.prahal.homelinux.net.
123.10.168.192.in-addr.arpa. 0	IN	PTR	hermes.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:11:39 CEST 2025
;; MSG SIZE  rcvd: 117


from cyclope, requesting its own interfaces IPs rDNS
$ host 192.168.10.12
12.10.168.192.in-addr.arpa domain name pointer cyclope.prahal.homelinux.net.
12.10.168.192.in-addr.arpa domain name pointer cyclope.
$ host 192.168.10.135
135.10.168.192.in-addr.arpa domain name pointer cyclope.prahal.homelinux.net.
135.10.168.192.in-addr.arpa domain name pointer cyclope.
$ dig -x  192.168.10.135

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.135
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55510
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;135.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
135.10.168.192.in-addr.arpa. 0	IN	PTR	cyclope.prahal.homelinux.net.
135.10.168.192.in-addr.arpa. 0	IN	PTR	cyclope.

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:08:28 CEST 2025
;; MSG SIZE  rcvd: 119
$ dig -x 192.168.10.12

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.12
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26675
;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;12.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
12.10.168.192.in-addr.arpa. 0	IN	PTR	cyclope.prahal.homelinux.net.
12.10.168.192.in-addr.arpa. 0	IN	PTR	cyclope.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:08:39 CEST 2025
;; MSG SIZE  rcvd: 118



from cyclope requesting hermes IP rDNS
$ host 192.168.10.123
123.10.168.192.in-addr.arpa domain name pointer hermes.prahal.homelinux.net.
$ dig -x 192.168.10.123

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.123
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32509
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;123.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
123.10.168.192.in-addr.arpa. 55	IN	PTR	hermes.local.

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:09:51 CEST 2025
;; MSG SIZE  rcvd: 82


from hermes requesting cyclope IP rDNS
$ host 192.168.10.12
12.10.168.192.in-addr.arpa domain name pointer cyclope.local.
$ host 192.168.10.135
135.10.168.192.in-addr.arpa domain name pointer cyclope.prahal.homelinux.net.
$ dig -x 192.168.10.12

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.12
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50041
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;12.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
12.10.168.192.in-addr.arpa. 113	IN	PTR	cyclope.local.

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:21:08 CEST 2025
;; MSG SIZE  rcvd: 82
$ dig -x 192.168.10.135

; <<>> DiG 9.20.7-1-Debian <<>> -x 192.168.10.135
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58156
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;135.10.168.192.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
135.10.168.192.in-addr.arpa. 113 IN	PTR	cyclope.local.

;; Query time: 4 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Apr 14 04:21:10 CEST 2025
;; MSG SIZE  rcvd: 83




So could it be pam 1.7 is working correctly while 1.5.3 wasn't?

Cheers,
Alban

    Alban> Is this change in domain resolution a regression or a fix ?

I think both behaviors are reasonable and so I do not propose to diverge
from upstream in this regard.

    Alban> Is this change in domain resolution a regression or a fix ?

I think both behaviors are reasonable and so I do not propose to diverge
from upstream in this regard.

?
diverge

I agree. This is a matter of policy and not a bug per se.

But I think this deserves an entry in the NEWS file and maybe in the
release notes as one can end up being unable to login via ssh without a
change to his pam configuration after the upgrade from 15.3 to 1.7.0.
Not everyone reads the release notes but at least that could help them
sort out their setup once broken.

So I will bug report debops (this rules comes from this ansible
collections project) to add the '.local' avahi domain to the pam
allowed domains.

Cheers
Alban

?
diverge

I agree. This is a matter of policy and not a bug per se.

But I think this deserves an entry in the NEWS file and maybe in the
release notes as one can end up being unable to login via ssh without a
change to his pam configuration after the upgrade from 15.3 to 1.7.0.
Not everyone reads the release notes but at least that could help them
sort out their setup once broken.

So I will bug report debops (this rules comes from this ansible
collections project) to add the '.local' avahi domain to the pam
allowed domains.

Can I close this bug report now, or should I wait for the NEWS entry to
have been added?

Cheers
Alban

The issue might be more serious than I initially though.
Due to an issue with a particular option of avahi it ended up
not starting anymore.
And then pam_access failed on me again due to being unable to resolve
at all (before it was failing back to mdns .local). It was not
complaining about a .local name anymore but about plain IP. At time
IPv4 at other time link-local IPv6.
I ended up adding both my local LAN IPv4 network IPs and IPv6 link-
local fe80::0/64 to my access.conf but the fact the issue is not about
resolving to .local instead of the dhcp/DNS LAN domain. But not being
able to resolve to the DNS LAN domain name at all.

Though I won't be able to work on this issue seriously for at least 10
days, I preferred to raise the issue. I will be able to do tests at
time, but I don't expect much more.

Cheers,
Alban

Have you seen my update on this issue ? Ie the release is close.
I don't know how to diagnose this  issue further (ie why LAN domain is
not resolved at all by pam_access). And I don't think I will be able to
devote enough time to learn how to diagnose that until the release.
Obviously it only affects users using pam_access but still it seems it
will lock them out of their boxes.
It could well be an upstream issue. It could also be debops setups are
the only left using pam_access. Or that pam 1.7 is not yet widespread.

Though the issue should probably be moved to the upstream bug tracker.

Best Regards
Alban


On Thu, 17 Apr 2025 20:36:34 +0200 Alban Browaeys <prahal@yahoo.com> wrote:
<hartmans@debian.org>
fix
the
without
1.7.0.
entry
about
10

    Alban> Have you seen my update on this issue ? Ie the release is
    Alban> close.  I don't know how to diagnose this issue further (ie
    Alban> why LAN domain is not resolved at all by pam_access). And I
    Alban> don't think I will be able to devote enough time to learn how
    Alban> to diagnose that until the release.  Obviously it only
    Alban> affects users using pam_access but still it seems it will
    Alban> lock them out of their boxes.  It could well be an upstream
    Alban> issue. It could also be debops setups are the only left using
    Alban> pam_access. Or that pam 1.7 is not yet widespread.

    Alban> Though the issue should probably be moved to the upstream bug
    Alban> tracker.

I don't think pam_access is very widespread, so I do not consider this
release critical.
If we find a code change that makes things better I'd be open to working
on the necessary paperwork to get it into a stable release.

At this point I don't understand the issue well enough to report it to
upstream.
I think what we know is that under some circumstances pam_access does
not work well with reverse resolving the names of local machines when
avahi is running.
At first you thought it was that avaahi was being preferred and .local
ended up getting preferred to .lan.
But now it sounds more complicated.

This is not an issue I'm going to dedicate a lot of time to either.
One thing you could do to help would be to put together a test case to
reproduce--especially if you could do that as a simple container config
or similar.

Le dimanche 25 mai 2025 à 10:38 -0600, Sam Hartman a écrit :

Agreed that this is a niche issue.

It turns out that no. At least as far as I remind, I though at first it
was avahi taking over. But I ended disabling avahi and the LAN domain
was no resolved any better, now it was erroring because it could not
match to the plain IP instead of the avahi fqdn, when it should have
resolved to the local LAN domain names.
my DHCP/DNS is dnsmasq.

Good idea, though it will likely have to wait after Trixie release.

Best regards,
Alban