1. 项目概述从“密码”到“钥匙”理解SSH登录的本质如果你用过Linux服务器或者捣鼓过GitHub、GitLab那“SSH”这个词对你来说肯定不陌生。它就像一把万能钥匙能让你安全地远程登录到另一台计算机上执行命令、传输文件。但很多朋友对SSH的理解可能就停留在“输个密码连上去”的阶段。今天我们就来彻底拆解SSH的两种核心登录方式密码登录和公钥认证登录。这不仅仅是知道怎么用更要搞懂它们背后的原理、各自的优劣以及为什么在稍微严肃点的场景下大家都会推荐你使用公钥认证。简单来说SSH登录就是你向远程服务器证明“我是我”的过程。密码登录就像你知道一个只有你和服务器才知道的暗号每次进门都对暗号。而公钥认证登录则更像你有一把独一无二的物理钥匙私钥服务器那里有对应的锁芯公钥钥匙插进去一转门就开了根本不用说话。后者的安全性、便捷性远超前者的原因我们后面会详细展开。无论你是刚接触服务器运维的开发者还是经常需要远程连接各种服务彻底搞懂这两种机制能帮你避免很多安全陷阱提升工作效率。2. SSH登录机制深度解析从握手到认证要理解登录得先看看SSH连接建立时都发生了什么。这不是一个简单的“请求-响应”而是一套严谨的协议握手流程。2.1 SSH连接建立的全过程当你执行ssh userhost命令时你的SSH客户端和远程的SSH服务端会开始一次加密的“对话”。这个过程大致分为几个阶段TCP连接建立客户端向服务器的22端口默认发起连接。协议版本协商客户端和服务端互相通报自己支持的SSH协议版本如SSH-2.0并协商使用双方都支持的最高版本。现在基本都使用SSH-2因为它修复了SSH-1的许多安全漏洞。密钥交换算法协商这是关键一步。双方会协商出一套用于本次会话的加密算法包括密钥交换算法如diffie-hellman-group14-sha256用于在不安全的网络上安全地生成一个只有双方知道的共享秘密。加密算法如aes256-gcmopenssh.com用于后续所有通信的加密。消息认证码算法如hmac-sha2-256用于验证数据在传输中未被篡改。压缩算法可选。生成会话密钥使用协商好的密钥交换算法客户端和服务端会各自计算出一个相同的“会话密钥”。这个密钥是后续所有对称加密的基础。整个交换过程即使被监听攻击者也无法推算出这个会话密钥。用户认证在加密通道建立好后才轮到我们今天的主题——认证。服务器会向客户端发起认证请求客户端则根据配置选择使用密码或公钥等方式来证明身份。会话请求认证通过后客户端会请求一个交互式会话比如启动一个shell或执行某个特定命令。理解这个过程很重要它说明了认证是在一个已经加密的安全通道内进行的。这意味着即使你使用密码登录你的密码也是在加密后才传输的不会被明文窃听。但这不代表密码登录就安全风险点在于密码本身可能被暴力破解或泄露。2.2 密码认证便捷背后的隐患密码认证是最直观的方式。其流程可以概括为服务器通过安全通道向客户端发送认证挑战。客户端将用户输入的密码经过哈希等处理后发送给服务器。服务器将收到的密码哈希与本地存储的密码哈希通常是/etc/shadow中的记录进行比对。匹配则成功否则失败。它的核心问题不在于传输过程而在于“密码”这个凭证本身弱密码风险如果用户设置了简单密码如123456,password攻击者可以通过暴力破解工具在加密通道内持续尝试直到猜中为止。服务器虽然可以记录失败次数并封禁IP但攻击者可以使用代理IP池来绕过。密码泄露风险如果你在多处使用相同密码其中一处服务被“拖库”那么你的服务器也岌岌可危。无法实现自动化脚本或CI/CD工具需要自动登录服务器时无法交互式地输入密码。易受中间人攻击虽然SSH-2通过密钥交换能有效防范中间人攻击但在首次连接一个未知主机时如果用户盲目接受了主机的指纹后续仍存在理论上的风险。注意很多新手会疑惑既然加密了为什么还说密码登录不安全关键在于安全是分层的。加密解决了“窃听”问题但没解决“凭证强度”和“泄露”问题。攻击者不需要破解加密算法他只需要猜对你的密码即可。2.3 公钥认证非对称加密的优雅实践公钥认证利用了非对称加密也称公私钥加密的原理。你需要生成一对密钥一个私钥和一個公钥。私钥必须绝对保密存放在客户端本地如~/.ssh/id_rsa。它就像你的家门钥匙绝不能给别人。公钥可以公开需要上传到服务器的对应用户目录下~/.ssh/authorized_keys。它就像一把公开的锁谁都可以看到但只有对应的私钥才能打开。认证流程如下客户端发起认证并告知服务器自己想使用的公钥ID。服务器检查该用户的authorized_keys文件中是否存在这个公钥。如果存在服务器生成一个随机字符串挑战并用该公钥加密。服务器将加密后的挑战发送给客户端。客户端使用本地对应的私钥解密这个挑战得到原始字符串。客户端将解密出的字符串与一个会话标识符合并计算其MD5哈希值然后将这个哈希值发回给服务器。服务器自己也用同样的方式计算一次哈希值。如果两个哈希值匹配则证明客户端拥有对应的私钥认证成功。这个过程的美妙之处在于无需传输秘密私钥始终在客户端从未在网络中传输。传输的只是公钥加密的挑战和计算出的哈希值即使被截获也无法反向推导出私钥。抵抗暴力破解私钥通常是非常长如2048位以上的随机字符串其可能性空间巨大暴力破解在现有计算能力下不可行。便于自动化私钥可以设置密码短语保护也可以不设置不推荐。不设置时可实现完全免交互登录非常适合自动化脚本。可追溯性每个公钥都是唯一的。在服务器日志中你可以清晰地看到是哪个公钥登录的便于审计。3. 核心细节解析与实操要点理解了原理我们来看看具体怎么操作以及其中有哪些必须注意的细节。3.1 生成与管理SSH密钥对在客户端生成密钥对是第一步通常使用ssh-keygen命令。ssh-keygen -t rsa -b 4096 -C your_emailexample.com-t rsa指定密钥类型为RSA。也可以选择ed25519更安全更快但某些老旧系统不支持。-b 4096指定密钥长度为4096位。2048位是旧标准4096位更安全。-C comment添加一个注释通常用邮箱方便标识这个密钥的归属。执行命令后它会询问你密钥的保存路径默认~/.ssh/id_rsa和是否设置密码短语。关于密码短语的深度解析这是一个重要的安全增强层。它为私钥本身加了一把锁。设置密码短语每次使用该私钥时如ssh登录、git push都需要输入这个短语来解密私钥文件。这样即使私钥文件被盗攻击者没有密码短语也无法使用。对于桌面环境可以使用ssh-agent这类密钥管理器只需输入一次密码短语即可在整个会话中缓存解密后的私钥平衡了安全与便利。不设置密码短语私钥即拿即用最方便但也最危险。一旦私钥泄露服务器门户大开。仅推荐用于完全受控的自动化环境如CI/CD服务器并且必须严格限制该私钥的文件权限和访问范围。密钥文件权限——一个必踩的坑SSH协议对文件权限有严格检查权限过宽会直接导致认证失败。客户端~/.ssh目录权限应为700(drwx------)私钥文件如id_rsa权限应为600(-rw-------)。公钥文件.pub权限可以宽松些但通常也设为644。服务端用户家目录、~/.ssh目录以及~/.ssh/authorized_keys文件的权限都不能对组或其他用户有写权限。通常~/.ssh为700authorized_keys为600。实操心得如果你遇到Permissions 0644 for ‘~/.ssh/id_rsa’ are too open.这类错误别慌用chmod命令修正权限即可。养成习惯生成密钥后第一件事就是检查并设置正确权限。3.2 部署公钥到服务器将公钥部署到服务器有两种主流方法方法一使用ssh-copy-id命令最推荐ssh-copy-id -i ~/.ssh/id_rsa.pub userhostname这个命令会自动将你的公钥追加到服务器对应用户的~/.ssh/authorized_keys文件末尾并帮你设置好正确的文件权限。这是最安全、最便捷的方式。方法二手动复制查看本地公钥内容cat ~/.ssh/id_rsa.pub登录目标服务器暂时还需要用密码或其他方式。确保~/.ssh目录存在mkdir -p ~/.ssh将公钥内容追加到authorized_keys文件echo 你的公钥字符串 ~/.ssh/authorized_keys修正权限chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys3.3 配置SSH客户端以优化体验直接使用ssh userhost是最基本的。但通过配置~/.ssh/config文件可以极大提升效率和体验。# ~/.ssh/config 文件示例 Host myserver # 自定义别名 HostName 192.168.1.100 # 实际主机名或IP User zhangsan # 默认登录用户名 Port 2222 # 如果服务器SSH端口不是22 IdentityFile ~/.ssh/id_rsa_myserver # 指定使用的私钥文件 # 以下是优化参数 ServerAliveInterval 60 # 每60秒发送一个保活包防止连接被防火墙断开 ServerAliveCountMax 3 # 最多发送3次保活包无响应则断开 Compression yes # 启用压缩在低速网络上提升交互体验 ControlMaster auto # 启用连接共享对同一主机多次连接复用同一个TCP连接 ControlPath ~/.ssh/%r%h:%p ControlPersist 4h # 主连接保持4小时 Host github.com # 为GitHub配置 User git IdentityFile ~/.ssh/id_github # 为GitHub使用独立的密钥配置好后你只需要执行ssh myserver即可连接无需再输入用户名、IP和端口。4. 实操过程与核心环节实现让我们通过一个完整的场景将上述知识串联起来为一台新Ubuntu服务器配置SSH并禁用密码登录。4.1 服务器端初始安全配置首次登录使用密码假设你通过云服务商的控制台获取了服务器的IP和初始密码。ssh root你的服务器IP # 首次登录会提示主机密钥指纹确认无误后输入yes创建新管理用户避免直接使用rootadduser deploy # 创建一个名为deploy的用户按提示设置密码等信息 usermod -aG sudo deploy # 将deploy用户加入sudo组获得管理员权限为新用户配置公钥登录在你的本地电脑生成密钥对如果还没有ssh-keygen -t ed25519 -C deployproduction将公钥上传到服务器的deploy用户# 在本地执行 ssh-copy-id deploy你的服务器IP测试新用户公钥登录ssh deploy你的服务器IP如果成功你应该无需输入密码即可登录。4.2 强化SSH服务端配置现在以deploy用户登录服务器修改SSH服务端配置/etc/ssh/sshd_config。修改前务必先备份sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup sudo nano /etc/ssh/sshd_config找到并修改以下关键参数# 更改默认端口减少自动化扫描攻击可选但建议 Port 2222 # 改为一个1024-65535之间的非知名端口 # 禁止root用户直接通过SSH登录 PermitRootLogin no # 禁用密码认证强制使用公钥认证 PasswordAuthentication no ChallengeResponseAuthentication no # 通常与密码认证相关 # 启用公钥认证 PubkeyAuthentication yes # 允许使用空密码短语的密钥建议设为no以提高安全性 PermitEmptyPasswords no # 指定允许登录的用户白名单机制更安全可选 AllowUsers deploy # 配置登录失败处理 MaxAuthTries 3 # 最大认证尝试次数 ClientAliveInterval 300 # 客户端活动检测间隔秒 ClientAliveCountMax 2 # 客户端无响应最大次数超过则断开修改后必须重启SSH服务sudo systemctl restart sshd重要警告在重启sshd之前务必保持一个当前登录会话的窗口打开并用另一个终端窗口测试新配置是否能成功登录。如果配置有误导致无法登录你还可以通过原来的会话窗口进行修复。这是运维中的一条铁律。4.3 防火墙配置如果服务器启用了防火墙如ufw或firewalld需要放行新的SSH端口。对于Ubuntu的ufwsudo ufw allow 2222/tcp # 允许新端口 sudo ufw deny 22/tcp # 禁用旧端口可选确认新端口可用后再执行 sudo ufw reload5. 常见问题与排查技巧实录即使按照步骤操作也难免会遇到问题。下面是我在多年实践中总结的排查清单。5.1 公钥认证失败排查流程当ssh -v userhost-v是verbose模式可加多个v如-vvv获取更详细日志显示Permission denied (publickey)时请按以下顺序排查客户端侧检查私钥路径与权限ssh命令是否使用了正确的私钥检查~/.ssh/config中IdentityFile的配置或通过ssh -i /path/to/key指定。确保私钥权限为600。私钥格式某些旧系统可能不支持OpenSSH的新格式。可以用ssh-keygen -p -f your_key尝试转换或检查。ssh-agent如果你为私钥设置了密码短语是否已将私钥添加到ssh-agent并解锁用ssh-add -l查看已加载的密钥列表。服务端侧检查需要能通过其他方式登录服务器查看公钥是否就位登录服务器检查~/.ssh/authorized_keys文件内容是否正确、完整末尾没有多余空格或换行符。可以用cat -A ~/.ssh/authorized_keys查看不可见字符。文件权限这是最常见的原因。确保用户家目录chmod 755 ~或chmod 700 ~不能有组/其他用户写权限。.ssh目录chmod 700 ~/.ssh。authorized_keys文件chmod 600 ~/.ssh/authorized_keys。SELinux/AppArmor在某些严格的安全策略下这些安全模块可能会阻止SSH读取.ssh目录。可以尝试临时禁用测试setenforce 0或添加相应策略。sshd配置确认/etc/ssh/sshd_config中PubkeyAuthentication yes已启用并且没有通过DenyUsers或AllowUsers限制该用户。网络与防火墙确认能连接到服务器的SSH端口telnet hostname 22或nc -zv hostname 22。检查服务器防火墙和云服务商的安全组规则是否允许来自你客户端IP的连接。5.2 高频问题速查表问题现象可能原因解决方案Permission denied (publickey).1. 公钥未上传或内容错误。2. 文件权限问题。3.sshd_config中公钥认证未开启。1. 用ssh-copy-id重新上传核对内容。2. 按上文检查并修正家目录、.ssh、authorized_keys权限。3. 检查配置并重启sshd。Agent admitted failure to sign using the key.ssh-agent 未加载或未解锁该私钥。执行ssh-add ~/.ssh/your_private_key添加并输入密码短语。Could not open a connection to your authentication agent.ssh-agent 进程未运行。执行eval $(ssh-agent -s)启动代理。Connection closed by remote host.服务器sshd配置错误或达到最大连接数/认证尝试次数。检查服务器/var/log/auth.log或/var/log/secure日志。确认MaxAuthTries,MaxSessions等配置。SSH连接缓慢DNS反向解析问题。在服务器sshd_config中设置UseDNS no然后重启服务。Git操作仍要密码Git仓库使用的仍是HTTPS协议而非SSH协议。将远程仓库URL改为SSH格式git remote set-url origin gitgithub.com:user/repo.git5.3 关于VSCode Remote-SSH等工具的特别提示很多开发者喜欢用VSCode的Remote-SSH插件连接远程服务器。其本质也是调用系统的SSH命令。因此所有上述配置尤其是~/.ssh/config对它同样有效。如果你遇到VSCode连接时反复弹出密码输入框或者提示“验证失败”请首先在系统终端里用命令行ssh your_host_alias测试是否能连通。这是最直接的诊断方式。确保VSCode使用的SSH可执行文件路径正确通常它使用系统自带的。检查VSCode Remote-SSH的日志通过命令面板Remote-SSH: Show Log里面通常会有更详细的错误信息往往就是权限问题或密钥路径问题。最后关于密钥管理我个人强烈建议为不同的用途和服务使用不同的密钥对。比如工作服务器一套密钥个人服务器一套GitHub一套。这样即使某一个私钥泄露也不会波及其他系统。把~/.ssh/config文件管理好为每个主机配置对应的IdentityFile切换起来也非常方便。安全与便利的平衡就体现在这些细节的实践中。