限制linux用户通过ssh访问的核心方法是编辑sshd_config文件，1.备份配置文件防止出错；2.使用allowusers或denyusers控制特定用户访问；3.通过allowgroups或denygroups按用户组限制；4.重启ssh服务并测试配置语法。ssh访问控制至关重要，可减少攻击面、落实最小权限原则、满足合规要求，并提升系统安全性。此外，还可结合ip限制、更改默认端口、禁用密码认证、设置登录尝试次数及防火墙策略等多维度手段强化安全。配置时需避免常见误区，如未测试即重启服务、误解规则优先级、依赖单一策略及允许root直接登录等。
限制linux用户通过SSH访问，核心思路是利用SSH服务器的配置文件sshd_config进行精细化控制。这不仅能有效提升系统安全性，还能根据不同用户的职责，分配其合理的访问权限，避免不必要的风险暴露。
解决方案
要限制Linux用户通过SSH访问，主要操作集中在修改/etc/ssh/sshd_config文件。这个文件是SSH服务器的“大脑”，所有的访问策略都在这里定义。
- 备份配置文件： 在进行任何修改之前，务必备份当前的sshd_config文件。这是黄金法则，可以避免因配置错误导致无法登录的窘境。
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
- 编辑配置文件： 使用你喜欢的文本编辑器（如nano或vim）打开sshd_config。
sudo nano /etc/ssh/sshd_config
- 使用AllowUsers或DenyUsers：
- AllowUsers： 如果你只想允许少数几个用户登录，这是最推荐的方式。它会明确列出允许登录的用户名，未列出的用户将无法登录。
AllowUsers user1 user2 admin@192.168.1.100
这里user1和user2可以从任何地方登录，而admin只能从192.168.1.100这个IP地址登录。
- DenyUsers： 如果你只想禁止少数几个用户登录，而允许其他所有用户，可以使用这个。
DenyUsers guest testuser
guest和testuser将被禁止登录。
- 重要提示： DenyUsers的优先级高于AllowUsers。这意味着如果一个用户同时出现在DenyUsers和AllowUsers中，他将无法登录。
- AllowUsers： 如果你只想允许少数几个用户登录，这是最推荐的方式。它会明确列出允许登录的用户名，未列出的用户将无法登录。
- 使用AllowGroups或DenyGroups：
- AllowGroups： 允许特定组内的所有用户登录。
AllowGroups developers sysadmins
- DenyGroups： 禁止特定组内的所有用户登录。
DenyGroups visitors
- 重要提示： DenyGroups的优先级高于AllowGroups。
- AllowGroups： 允许特定组内的所有用户登录。
- 重启SSH服务： 修改sshd_config后，必须重启SSH服务才能使更改生效。
sudo systemctl restart sshd
在重启前，强烈建议先测试配置文件的语法是否正确，以防服务启动失败：
sudo sshd -t
如果没有输出任何错误，说明语法没问题。
为什么限制SSH访问如此重要？
在我看来，限制SSH访问绝不仅仅是“做个样子”那么简单，它是服务器安全的第一道，也是最关键的一道防线。想想看，如果一个系统管理员对所有用户都敞开SSH大门，那和把家门钥匙挂在门外有什么区别？
首先，最直接的原因是减少攻击面。互联网上无时无刻不在发生针对SSH端口的暴力破解和自动化扫描。你可能觉得自己的密码够复杂，但面对机器不间断的尝试，总有那么一丝风险。通过限制访问，比如只允许特定IP、特定用户登录，你瞬间就过滤掉了绝大多数的“噪音”和恶意尝试，让攻击者连尝试的机会都没有。
其次，这关乎权限管理和最小权限原则。不是每个人都需要SSH到服务器上，也不是每个需要SSH的人都应该拥有相同的权限。比如，一个开发人员可能只需要访问特定的代码库，而不需要root权限或访问数据库。限制SSH访问，正是落实“最小权限原则”的直接体现，确保用户只能做他们被允许做的事情，从而避免误操作或恶意行为造成的损害。
再者，从合规性的角度看，很多行业规范和安全审计都要求对服务器访问进行严格控制。明确的SSH访问策略，是满足这些要求的基础。我个人就遇到过因为SSH权限管理不善，导致审计不通过，不得不紧急整改的案例。所以，这不仅仅是技术问题，也是管理问题。
最后，说实话，这也算是一种心理安慰。当你明确知道只有少数几个“可信”的用户或IP可以碰你的服务器时，那种安全感是不言而喻的。服务器的安全，很多时候就是由这些看似微小的细节堆砌起来的。
除了用户和组，还能通过哪些方式限制SSH登录？
sshd_config的强大之处在于它提供了多维度的限制能力，远不止用户和组那么简单。在我日常运维中，经常会结合使用这些策略，构建更坚固的防线。
一个常见的思路是基于IP地址的限制。除了前面提到的AllowUsers user@host这种针对特定用户的IP限制，你还可以使用ListenAddress来限制SSH服务只在服务器的特定网络接口或IP地址上监听。例如，如果你的服务器有内外两张网卡，你可以让SSH只在内网IP上监听，这样外网就无法直接连接。
ListenAddress 192.168.1.10
更进一步，改变默认SSH端口（Port 22）也是一种常见的“隐匿”策略。虽然这并非真正的安全增强，因为它只是让那些自动化扫描器少发现你，但对于过滤掉大量的低级攻击尝试还是有用的。
Port 2222
然后是认证方式的强化。我个人强烈推荐禁用密码认证，只允许密钥认证。密码再复杂也可能被字典攻击或暴力破解，但密钥对的安全性要高得多。
PasswordAuthentication no PubkeyAuthentication yes
此外，你还可以限制登录尝试次数和登录宽限时间。MaxAuthAttempts可以限制用户在断开连接前可以尝试多少次密码，而LoginGraceTime则限制了用户在多少秒内必须完成认证。这些都能有效减缓暴力破解的速度。
MaxAuthAttempts 3 LoginGraceTime 60
最后，别忘了系统级别的防火墙（如iptables或firewalld）。虽然它们不是sshd_config的一部分，但它们是限制SSH访问的另一层关键防护。你可以在防火墙层面直接拒绝来自特定IP范围的SSH连接，这比在sshd_config中配置DenyUsers或DenyGroups更早地拦截了恶意流量，减轻了SSH服务器的负担。在我看来，一个健全的服务器安全策略，必然是sshd_config和防火墙双管齐下的结果。
配置sshd_config时有哪些常见误区和注意事项？
配置sshd_config，就像在玩一场高风险的游戏，一旦失误，很可能就把自己锁在门外。我见过太多人，包括我自己，在早期都犯过类似的错误。所以，有些“坑”是必须要提前知道的。
最最常见的，也是最致命的误区就是忘记测试和备份，直接修改并重启服务。想象一下，你修改了一个参数，手一抖敲错了，或者某个指令的顺序搞错了，然后自信满满地sudo systemctl restart sshd。结果呢？服务启动失败，或者虽然启动了但你配置的规则把自己也给禁了。此时如果你没有其他登录方式（比如物理控制台或带外管理），那真是叫天天不应叫地地不灵了。所以，备份和**sshd -t**（测试配置语法）是雷打不动的两步。
另一个容易犯的错误是对指令的优先级理解不清。前面提到了DenyUsers和DenyGroups的优先级高于AllowUsers和AllowGroups。很多人会想当然地认为“允许”的规则应该更优先，结果导致一些本来想允许的用户也被拒绝了。在配置多条规则时，务必清楚它们的生效顺序。
还有，过度依赖单一的安全策略。比如，只改了端口号就觉得万事大吉，或者只用了AllowUsers就觉得高枕无忧。实际上，一个健壮的安全体系是多层防御的结果。sshd_config很强大，但它只是其中一环。防火墙、强密码策略、定期更新、入侵检测系统等等，都是不可或缺的部分。
最后，也是一个我个人非常推崇的实践：禁用root用户直接登录。PermitRootLogin no这个选项几乎是所有生产环境的标配。即使你限制了root用户只能从特定IP登录，也建议禁用。因为root权限过大，一旦被攻破，后果不堪设想。正确的做法是允许普通用户登录，然后通过sudo命令在需要时提升权限。这增加了攻击者获取完整控制的难度，也留下了操作日志，方便追踪。
总而言之，配置sshd_config需要细心、耐心，并且要有一颗“我可能会把自己锁在外面”的警惕心。多一分谨慎，少一分麻烦。
