openssh 无法基于客户端 mac 地址做访问控制，因其工作在传输层，无法获取或验证 l2 的 mac 地址；替代方案包括：本地防火墙按 mac+ip 限直连场景、dhcp 绑定 ip-mac 后白名单管控、或推荐的密钥认证+ip 网段限制+网络隔离组合策略。
OpenSSH 本身不支持基于客户端 MAC 地址的身份验证或访问控制。MAC 地址工作在数据链路层（L2），而 SSH 运行在传输层（L4）之上，其连接建立时已处于 IP 层（L3）之后，服务端无法直接获取、也无法可靠验证发起连接的原始物理网卡 MAC 地址——尤其当连接经过路由器、NAT、代理或 VLAN 等中间设备时，源 MAC 早已被替换。
因此，“配置 OpenSSH 仅允许特定 MAC 地址登录”这一需求无法通过 sshd_config 或 OpenSSH 原生功能实现。
但你可以通过以下分层替代方案达成等效的安全目标：
-
在网络层做源头准入控制
在 SSH 服务器所在主机的本地防火墙（如nftables或iptables）中，结合arp表或桥接规则（仅限二层直连场景）进行 MAC 限制：- ✅ 仅适用于：客户端与服务器同属一个广播域（即直连或同一交换机下无三层设备介入）；
- ❌ 不适用于：跨子网、经由路由器/NAT、使用 Wi-Fi AP 中继、或云服务器等典型部署场景。
示例（nftables，仅限直连局域网）：
# 先确认客户端 IP 已绑定固定 MAC（如 via static ARP） arp -s 192.168.1.100 aa:bb:cc:dd:ee:ff # 在 nftables INPUT 链中匹配源 MAC + 目标端口 22 nft add rule inet filter input ether saddr aa:bb:cc:dd:ee:ff tcp dport 22 accept nft add rule inet filter input tcp dport 22 drop
-
用 DHCP + IP-MAC 绑定 + IP 白名单组合管控
若你控制局域网 DHCP 服务器（如 dnsmasq、ISC DHCP）：- 为可信设备分配固定 IP 并绑定 MAC；
- 在
sshd_config中设置ListenAddress为内网 IP，并配合防火墙只放行这些固定 IP 的 22 端口请求； - 效果等同于“只让这些设备连”，且比 MAC 控制更稳定、可审计、易维护。
-
真正推荐的生产级做法：证书 + 主机信任 + 网络隔离
- ✅ 强制使用 SSH 密钥对认证（禁用密码登录）；
- ✅ 将公钥按设备/人员粒度写入
~/.ssh/authorized_keys，并启用no-port-forwarding,no-X11-forwarding,command="..."等限制； - ✅ 配合系统防火墙（如
nftables）限制tcp dport 22仅来自私有网段（192.168.0.0/16,10.0.0.0/8,172.16.0.0/12）； - ✅ 物理或逻辑网络层面隔离 SSH 管理网段（例如单独 VLAN、管理口直连、跳板机前置）。
本质上，MAC 地址不是身份凭证，而是临时拓扑标识。安全边界应建在可验证的身份（密钥/证书）+ 可控的网络路径（IP/子网策略）+ 最小权限执行环境之上，而非不可靠的硬件地址。
不复杂但容易忽略。
