The easiest way to test whether pf(4) is interfering with your YubiKey is to
temporarily turn off pf(4) (`doas pfctl -d`) and test. If the problem persists
then pf(4) is not the cause.
Turn pf(4) back on again after your test (`doas pfctl -e` or `doas reboot`).
Note: Turning off pf(4) should cause no issues in your case as your rules are
very simple and contain no NAT, forwarding or redirection. You just loose a bit
of protection which will not matter as long as you don’t have services running
that would otherwise be blocked by your rules.
FWIW: I don’t use YubiKey but I think it is highly unlikely that pf(4) rules
would interfere with its function. If I understand the YubiKey functionality
correctly it will work on with ssh(1) on the client to "provide" the private
key and ssh(1) will communicate with the server as it would normally.
HTH
Mike
> Am 10.09.2024 um 18:09 schrieb WATANABE Takeo <t...@kasaneiro.jp>:
>
> on Tue, 10 Sep 2024 16:08:07 +0200
> "Peter N. M. Hansteen" <pe...@bsdly.net> wrote:
>
>> On Tue, Sep 10, 2024 at 08:32:05PM +0900, WATANABE Takeo wrote:
>>> I found out that I can log in with normal public key
>>> cryptography authentication (ed25519) in the same pf.conf environment,
>>> and that I can log in with ed25519-sk key authentication if I stop pf.
>>>
>>> It occurred to me again that the pf.conf I had written might be the problem.
>>
>> It should not matter whether PF is enabled or not, as long as the loaded
>> rules
>> allow your SSH traffic to pass. I would suspect the cause lies elsewhere.
>> Just to make sure: Is that at the end of your message the complete ruleset,
>> loaded in the normal way (and no scriptery that set network-relevant options
>> you are not showing here)?
>
> I have read my past emails that I have posted and I regret that
> I did not provide enough information on many things and that
> I did not answer the questions that I received.
>
> Therefore, I have written everything I know in this email.
>
> 1. Filtering rules for PF (Result of pfctl -sr)
>
> moegi# pfctl -sr
> block drop log all
> pass quick on vio0 proto tcp from any to any port = 80 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 443 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 53 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 25 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 465 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 587 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 993 flags S/SA
> pass quick on vio0 proto tcp from any to any port = 1522 flags S/SA
> pass quick on vio0 proto udp from any to any port = 53
> pass quick on vio0 proto udp from any to any port = 123
> pass quick on vio0 proto icmp all
> pass quick on vio0 proto ipv6-icmp all
>
> * Port 1522 is the listening port for sshd.
> No scripts are used.
>
> 2. hostname.vio0
>
> moegi# more hostname.vio0
> inet 160.16.212.251 0xfffffe00
> inet6 autoconf -autoconfprivacy -soii
> inet6 alias 2001:e42:102:1808:160:16:212:251 64
> up
> !route -nq add -inet6 default fe80::1%vio0
>
> The server uses the service of a Japanese server provider called Sakura VPS,
> which lends one IPv4 address and 64 IPv6 addresses.
>
> 3. The ifconfig results are sent as an attachment.
>
> 4. I am sorry to have written this far,
> but I also set the following sentence in sshd_config.
>
> PubkeyAuthOption verfiry-required
>
>
>>> tcp_services="{ http, https, domain, smtp, smtps, msa, imaps, 1522 }"
>>
>> Are we safe to assume that your sshd listens on port 1522?
>
> Yes, Yes.
>
>> Once again, it is impossible to offer really useful input unless we have
>> the entire configuration, at least the complete pf.conf along with any
>> hostname.vio0 or at least the ifconfig output for the interface.
>
> I think I have informed you of the points raised in these pages,
> but is there anything that I am missing or that I should look into further?
> I am not familiar with tcpdmp, so I would be grateful
> if you could give me some pointers on topics that would help me to use it.
>
> Sincerely yours,
>
> ---
> WATANABE, Takeo
> t...@kasaneiro.jp
>
> moegi# ifconfig
> lo0: flags=2008049<UP,LOOPBACK,RUNNING,MULTICAST,LRO> mtu 32768
> index 5 priority 0 llprio 3
> groups: lo
> inet6 ::1 prefixlen 128
> inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
> inet 127.0.0.1 netmask 0xff000000
> vio0:
> flags=248843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,AUTOCONF6TEMP,AUTOCONF6>
> mtu 1500
> lladdr 9c:a3:ba:02:0a:73
> index 1 priority 0 llprio 3
> groups: egress
> media: Ethernet autoselect
> status: active
> inet 160.16.212.251 netmask 0xfffffe00 broadcast 160.16.213.255
> inet6 fe80::9ea3:baff:fe02:a73%vio0 prefixlen 64 scopeid 0x1
> inet6 2001:e42:102:1808:160:16:212:251 prefixlen 64
> vio1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
> lladdr 9c:a3:ba:03:91:13
> index 2 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> vio2: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
> lladdr 9c:a3:ba:05:17:b3
> index 3 priority 0 llprio 3
> media: Ethernet autoselect
> status: no carrier
> enc0: flags=0<>
> index 4 priority 0 llprio 3
> groups: enc
> status: active
> pflog0: flags=141<UP,RUNNING,PROMISC> mtu 33136
> index 6 priority 0 llprio 3
> groups: pflog
> moegi#
