服务器怎么配置才能ssh?核心在于装好SSH服务端、放通端口、配好认证方式,三步到位。下面这套流程适用于绝大多数Linux云服务器,涵盖从连接到加固的完整路径。
配置SSH服务的基础步骤:从安装到首次连接
拿到一台新服务器,第一件事是确认系统里有没有SSH服务端,多数CentOS、Ubuntu镜像默认带有OpenSSH Server,但精简版系统往往没有预装。
确认与安装SSH服务端
先检查系统是否已安装并运行SSH服务,登录服务器控制台(通常通过VNC或云厂商网页终端),执行以下命令:
# 检查SSH服务状态 systemctl status sshd
如果提示没有这个服务,按系统类别安装:
- Debian/Ubuntu系:
apt update && apt install openssh-server -y - CentOS/RHEL系:
yum install openssh-server -y
安装完成后启动服务并设为开机自启:
systemctl start sshd systemctl enable sshd
修改核心配置项
SSH的配置文件在/etc/ssh/sshd_config,这是整个配置链路的主战场,建议先用cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak备份一份,再动手改。
以下三项是初配阶段必须确认的关键参数:
- 端口号:默认是22,如果公网服务器建议改成高位端口(如2222),能挡掉相当一部分扫描攻击,修改后记得放行防火墙对应端口。
- PermitRootLogin:默认可能是
prohibit-password或yes,安全起见,建议设为no,用普通用户登录后再su切换,避免root被暴力破解。 - PasswordAuthentication:初配阶段保持
yes方便连接,后期换密钥后一定要改成no。
每改完一项都要执行systemctl restart sshd让配置生效,注意,改端口和关root登录前,务必开着另一个终端会话测试,防止把自己锁在门外。
防火墙与安全组放行
很多用户苦于”SSH连接不上”,根源不在SSH配置本身,而是防火墙或云厂商安全组没放行端口。
- 云服务器安全组:登录云厂商控制台,找到实例所在的安全组,添加入站规则,放行TCP端口(默认22或你修改后的新端口),来源IP建议填你自己的公网IP网段,而非
0.0.0/0。 - 本机防火墙:
- CentOS:
firewall-cmd --permanent --add-port=22/tcp && firewall-cmd --reload - Ubuntu:
ufw allow 22/tcp && ufw enable
- CentOS:
ssh连接不上怎么排查:高频故障与解决路径
连接不上是配置过程中最常遇到的问题,按下面顺序排查,多数情况能在几分钟内定位根因。
第一层:网络可达性检查
先确认服务器IP是否通,用本地电脑执行ping 服务器IP,如果不通,重点查安全组和云厂商防火墙,若通,再测端口:
telnet 服务器IP 22
或者用nc -vz 服务器IP 22,端口不通时,排查方向集中在安全组未放行、SSH服务未监听、或系统防火墙拦截。
第二层:服务状态与端口监听
登录服务器控制台,执行:
netstat -tlnp | grep 22
如果结果里有sshd监听在0.0.0.0:22,说明服务正常,若什么都没输出,检查SSH服务是否崩溃,journalctl -u sshd查看日志报错,行业共识是,配置语法错误是导致服务起不来的首要原因,执行sshd -t可快速检测配置文件的语法问题。
第三层:密钥权限与认证方式
按上述步骤操作后仍连不上,且错误提示为Permission denied (publickey),说明密钥认证环节出问题,典型原因包括:
- 公钥没正确写入
~/.ssh/authorized_keys,注意是写入而非覆盖 .ssh目录权限必须是700,authorized_keys文件权限必须是600PermitRootLogin限制导致root无法密钥登录,需要切换到普通用户
云服务器ssh配置安全加固:密钥登录与防暴力破解
服务器能正常连接只是第一步,公网环境下SSH端口常年遭受扫描攻击,安全加固是配置工作中不可省略的一环。
启用密钥登录并禁用密码登录
密钥登录比密码登录安全得多,客户端生成密钥对:
ssh-keygen -t ed25519 -C "your_email@example.com"
按提示生成后,将公钥(.pub)追加到服务器的~/.ssh/authorized_keys中,这一步可用ssh-copy-id 用户名@服务器IP一行完成。
测试密钥登录确认无误后,回到sshd_config:
PasswordAuthentication no
重启服务后,基于密码的暴力破解基本失效。
限制登录来源与用户白名单
仅开放必要的登录通道是加固的核心思路,在sshd_config中追加:
AllowUsers deploy@192.168.1. webadmin
这样只允许deploy用户从168.1.网段登录,webadmin用户可从任意IP登录,业务复杂时,还可以配合Match Address块对不同来源设置差异化认证策略。
配置fail2ban拦截异常来源
即便密码登录已关闭,异常扫描依然消耗系统资源,安装fail2ban能自动封禁多次尝试失败的IP地址:
# CentOS yum install epel-release -y && yum install fail2ban -y # Ubuntu apt install fail2ban -y
配置文件在/etc/fail2ban/jail.local(新建),写入:
[sshd]
enabled = true
port = ssh
maxretry = 3
bantime = 3600
这样同一个IP试错3次即封禁1小时,据安全厂商的统计,多数自动化攻击来自少量固定IP段,自动封禁能有效降低服务器被攻破的概率。
不同场景下的SSH配置注意事项
配置SSH服务时,内网环境、公网环境、异地运维等场景对配置策略的要求有明显差异。
密码登录和密钥登录哪个更安全
密钥登录基于非对称加密算法(如ed25519),私钥长度达256位,理论上爆破难度远超密码方式,密码登录依赖于密码强度,弱密码或复用密码容易在撞库攻击中失守,2026年的运维环境下,公网服务器若无特殊原因(如自动化脚本依赖密码认证),一律建议采用密钥登录,内网跳板机等场景可保留密码登录,但需配合访问控制。
内网服务器与公网云服务器的配置差异
内网服务器通常处在隔离网络,默认端口22、密码登录尚可接受,公网云服务器则面临直接的端口扫描和口令猜解,配置策略应更激进,将端口改为非标准值(如22026或10022),关闭root远程登录,启用密钥认证,这一套组合能过滤掉绝大多数的自动化攻击。
异地运维有没有合理的配置方案
异地登录场景下,固定IP白名单可能不现实,面向这种情况,推荐使用SSH跳板机方案:所有运维人员先登录跳板机,再从跳板机跳转至目标服务器,跳板机上部署严格的审计与二次认证,目标服务器仅放行跳板机IP,另一种思路是使用云厂商提供的会话管理服务,免公网暴露端口。
常见的SSH配置问题解答
修改SSH端口后连不上怎么办
多数原因出在防火墙与安全组未同步放行新端口,通过云厂商网页的VNC登录服务器,执行ss -tlnp | grep 新端口确认监听状态,再检查iptables/firewalld/安全组的入站规则,不要忘记systemctl restart sshd重启服务使新端口生效。
配置SSH服务时误禁用了密码登录怎么恢复
出现这种情况,需要借助云厂商控制台的VNC或救援模式进入系统,将PasswordAuthentication no改回yes,重启sshd恢复密码登录,之后在确保密钥认证可用的情况下再关闭密码登录,服务器还剩一个其他开放端口可登入时,也可以尝试从那入口进入恢复。
多台服务器怎么批量分发SSH公钥
逐台进行ssh-copy-id效率太低,可将公钥写成一个文件放入配置管理工具中批量下发,或在初始化脚本里定义好公钥变量统一写入authorized_keys,Ansible的authorized_key模块和Shell循环都可以完成这项任务,行业共识是批量操作必须纳入统一的配置管理平台,避免人工维护导致的配置漂移。
SSH配置与加固并不复杂,核心链路是安装服务、修改配置、放行网络、切换密钥认证、做好访问控制,把这几步走完,服务器不管放在内网还是公网,基本都能稳妥地提供远程管理通道。
首发原创文章,作者:王坚,如若转载,请注明出处:https://idctop.com/article/583632.html




