SSH连接与文件上传全攻略：从密钥配置到rsync同步实操

1. 连接服务器这件事，先把底层逻辑搞清楚

1.1 你连接的到底是什么：IP、端口和SSH服务

很多刚接触服务器的朋友，第一次听到"连接服务器"这个概念时，脑子里通常是模糊的——我到底在连什么？是一个远程桌面？还是一个网页后台？都不是。你在做的，其实是让本机的一个客户端程序，和服务器上的一个服务进程之间，建立一条加密的通信通道。

可以把服务器理解成一栋只留了一个门牌号的写字楼。IP地址就是这栋楼所在的小区位置，端口号就是具体的房间号，而你输入的用户名和密码，就是前台验证身份的过程。三者缺一不可。Linux服务器默认开的是22号端口，跑的是sshd这个服务进程，你的电脑通过SSH协议去敲门。只要你用的是Linux系统的云服务器，几乎都是这个套路。

这个理解非常重要，因为后面所有的排查和配置，本质上都是在跟这三样东西打交道——IP通不通、端口通不通、身份验证通不通。很多同学一上来就照着教程敲命令，敲完发现连不上，就开始胡猜乱试，其实只要把这条链路在脑子里画清楚，问题定位会快得多。

1.2 为什么大家都在用SSH，而不是Telnet或者其他方式

讲个真实的事。我早期维护一台旧设备，厂商文档里写的还是Telnet方式登录。我敲下去之后，用户名密码竟然也通了，但旁边的前辈立刻让我退出来，说这玩意儿在网络上就是裸奔——你敲的每一个字符，包括密码，都是明文传出去的。这就好比你把自己的银行卡密码写在明信片上寄出去，沿途每个经手的人都能看见。

SSH的全称是Secure Shell，它的核心价值在于加密。从你输入用户名的第一个字符开始，客户端和服务端之间的通信就是加密的。即便有人抓包，抓到的也是一堆乱码。另外SSH还解决了身份伪造的问题，通过host key机制，客户端可以确认自己连接的确实是目标服务器，而不是中间被劫持到了一个假冒机器上。

这也就是为什么现在不管你是连Linux服务器、连交换机、连NAS，还是用Git拉代码，底层用的都是SSH协议。理解了这一层，你就知道，凡是远程管理类操作，优先想SSH准没错。

1.3 常见连接工具怎么选：命令行、终端软件还是VSCode

确定了要用SSH协议之后，剩下的问题就是用什么工具去连。这个选择其实很自由，但不同场景下的体验差异极大。

最基础的是系统自带的命令行SSH客户端。Windows 10以上的系统，PowerShell或CMD里直接敲ssh命令就能用，不需要装任何东西。macOS和Linux更是原生自带。这种方式的优点是干净、轻量，服务器上有什么命令就直接敲什么命令，没有任何中间层干扰。缺点是如果你需要同时管理多台服务器，每个窗口都要重新登录，操作效率略低。

终端类软件我平时用得比较多的是Termius和FinalShell。Termius跨平台，Windows、macOS、手机都能装，会话信息云端同步，适合有多台服务器、多设备管理需求的人。FinalShell国产，自带服务器性能监控图表，对新手很友好，文件上传下载也有图形界面可以拖拽。这类工具的本质仍然是SSH客户端，只是把会话管理、文件管理、性能监控做成了集成式体验，省去很多手动操作的繁琐。

如果你的开发场景是"远程改代码"，那VSCode的Remote-SSH插件是首选。装好插件后，用ssh user@ip的方式连接远程服务器，VSCode就会在远端启动一个server，让你像写本地代码一样直接编辑服务器上的文件，终端、调试器、插件全部走远程。编译在服务器上跑，代码在本地写，体验非常流畅。需要注意的一点是，Remote-SSH依赖本机的SSH配置，如果你的~/.ssh/config写得不规范，插件连不上时往往不会报很明确的错误，这个后面会专门讲。

2. 从密码到密钥：把连接做成"一次配置，长期使用"

2.1 第一次连接：密码登录的正确姿势

先说最基础的。假设你刚买了一台云服务器，拿到的信息包括一个公网IP、一个用户名（通常是root或ubuntu）、一个初始密码。那么第一次连接就是一行命令的事：

bash复制ssh root@你的服务器IP

如果你要指定端口，加-p参数：

bash复制ssh -p 22 root@你的服务器IP

第一次连接时，系统会提示你确认远程主机的指纹信息，问Are you sure you want to continue connecting (yes/no)?，这里输入yes回车。这个机制就是前面提到的host key校验——你的客户端会把服务器的公钥指纹记下来，下次连接时如果指纹变了，它会警告你，防止中间人攻击。所以遇到指纹警告的时候，千万别图省事直接跳过，先确认服务器是不是被人重装过系统或者做了什么改动。

密码登录虽然简单，但有几个天生缺陷：第一，密码本身容易被暴力破解，服务器挂到公网上半小时就能看到一堆失败的登录尝试；第二，每次连接都要输密码，频繁操作时很烦人；第三，如果你有多台服务器、多个密码，管理成本直线上升。所以我的建议是，密码登录只作为第一次进服务器的过渡方案，之后立刻换成密钥认证。

2.2 生成密钥对：公钥是锁，私钥是钥匙

密钥认证的核心逻辑，通俗地讲就是：你在本地生成一对钥匙，一把是公钥（Public Key），一把是私钥（Private Key）。公钥放到服务器上，私钥留在本地。连接时，服务器用公钥加密一个随机数发给客户端，客户端用私钥解开并返回结果，服务器验证通过后放行。整个过程私钥不会在网上传输，安全性远高于密码。

生成密钥对的命令很简单：

bash复制ssh-keygen -t ed25519 -C "你的备注信息"

这里尽量用ed25519而不是传统的RSA。ed25519密钥更短、生成速度快、安全性也足够高，而且现代Linux系统全部支持。命令执行后，一路回车即可，默认会存到~/.ssh/id_ed25519这个路径。如果提示输入passphrase，我建议设置一个——这是给私钥再加一层密码保护，即便私钥文件泄露，别人没有passphrase也解不开。

生成完之后，你会看到两个文件：id_ed25519是私钥，id_ed25519.pub是公钥。私钥无论如何都不要发给别人，公钥可以随便分发。注意检查一下本地私钥文件的权限，Linux和macOS下应该是600，Windows下也要确保私钥文件不能对其他用户开放读取。

2.3 把公钥上传到服务器并验证

上传公钥最省事的方式是ssh-copy-id命令：

bash复制ssh-copy-id -i ~/.ssh/id_ed25519.pub root@你的服务器IP

这个命令会自动把公钥追加到服务器的~/.ssh/authorized_keys文件里，并且自动处理目录权限。执行时需要输入一次密码——这是最后一次输入密码。如果没有ssh-copy-id命令（Windows上通常没有），可以手动追加：

bash复制cat ~/.ssh/id_ed25519.pub | ssh root@你的服务器IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

看到这里你可能已经能感受到，SSH相关的权限检查是很严格的：.ssh目录必须是700，authorized_keys文件必须是600，所有者必须是当前登录用户。任何一个权限过宽，sshd都会拒绝加载公钥。这是新手经常踩的一个坑，后面排查部分我会再细说。

验证方式很简单：直接ssh root@你的服务器IP，如果没提示输密码就直接进去，说明密钥认证已经生效。这时候再编辑服务器的/etc/ssh/sshd_config，把PasswordAuthentication改成no，重启sshd服务，以后密码暴力破解就对这台服务器失效了。

2.4 用 ~/.ssh/config 管理多台服务器

当你手里的服务器超过两三台，每次都敲root@IP就显得很傻了。我强烈建议在本地创建一个~/.ssh/config文件，把每台服务器的连接参数写进去，然后用一个简短别名替代所有重复信息。

text复制Host ali
    HostName 123.45.67.89
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519

Host stage
    HostName stage.example.com
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/id_ed25519_stage

Host prod
    HostName 120.24.xx.xx
    User ops
    Port 2222
    IdentityFile ~/.ssh/id_ed25519_prod

配置好之后，连接只需要ssh ali、ssh stage、ssh prod，其余参数自动带上。VSCode的Remote-SSH也是读取这个文件的，你在插件面板里能看到ssh ali这样的条目，点一下就连上了。这个配置文件是SSH客户端生态里最实用、也最容易被忽视的效率工具。

还有一个小技巧：如果你的本机系统和远程服务器系统用户名相同，可以省略User这一行；如果用的端口就是默认22，Port也可以不写。但写得全一点没坏处，尤其是当你换了一台新电脑，把这个文件原样拷过去，所有服务器连接配置就全部迁移了。

3. 连不上服务器的排查链路：从端口到认证的完整踩坑实录

3.1 先分清是"哪一层"出了问题

连接服务器失败，是运维和开发里最常见的场景之一。但很多人一失败就开始瞎试，改配置、换工具、重启服务器……一顿操作之后问题没解决，反而把环境搞得更乱。我的经验是，先按"链路分层"的思路，把问题定位到某一层，再针对性处理。

整个SSH连接链路可以拆成四层：网络层（服务器是否可达）、端口层（22端口是否放行）、认证层（用户名密码/密钥是否正确）、服务层（sshd是否正常运行及配置是否正确）。

下面这个表格是我常用的定位路径：

按这个顺序一路查下去，大多数问题都能在几分钟内定位。

3.2 端口不通：从防火墙到云安全组

先说一个我实际碰到过很多次的场景：ping能通，但ssh提示Connection timed out。这种情况基本可以断定是端口层出了问题。云服务器一般有两道防火墙：一道是服务器内部的iptables/firewalld/ufw，另一道是云厂商控制台里的安全组规则。很多人在服务器内部放开了端口，却忘了去云控制台放行，或者反过来，安全组放行了但服务器内部防火墙没开。

检查服务器内部防火墙：

bash复制# 查看firewalld状态（CentOS/RHEL系）
systemctl status firewalld
# 查看ufw状态（Ubuntu/Debian系）
ufw status

查看当前端口监听情况：

bash复制ss -lntp | grep 22

有监听说明sshd正在运行。再检查云厂商的安全组，在控制台里看入站规则里有没有放行TCP 22端口。另外提醒一点，有些云厂商的安全组修改后是立刻生效的，有些可能需要等一两分钟，别刚改完就急着测试。

顺带说一个相关的热搜词——"怎么检查校时服务器的123端口是否关闭"。123端口是NTP时间同步服务的端口，排查思路和22端口完全一致：服务器上先ss -lunp | grep 123看有没有监听，再用telnet 服务器IP 123或nc -uvz 服务器IP 123测试UDP端口通不通，最后看防火墙和安全组。这类端口排查的方法论是通用的，掌握了22端口的排查，123、3306、80、443等端口都是同一个套路。

3.3 认证失败的坑：Permission denied 的多种解法

连接时报Permission denied (publickey,password)，意思是认证层直接拒绝了你。最常见的几个原因：

第一，密码输错了。这个没什么好说的。但注意如果连续输错几次，sshd有可能会临时封禁你的IP，过几分钟再试即可。

第二，服务器上/etc/ssh/sshd_config里配置了PermitRootLogin no，你拿root账号去连就会被拒。解决方案是用一个有sudo权限的普通用户登录，或者到云控制台的VNC/救援模式里修改这个配置。

第三，密钥文件的权限不对。这个前面提过，.ssh目录和authorized_keys文件的权限只要过宽，sshd就会拒绝读取。服务器上执行一下这个命令修正：

bash复制chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys

第四，本地私钥文件权限过宽。在Linux和macOS下，如果id_ed25519的权限不是600，SSH客户端会直接拒绝使用这个key。修改方式：chmod 600 ~/.ssh/id_ed25519。

还有一个相似场景是Samba服务器报"用户名密码错误"。很多人以为和SSH一样是密码忘了，但Samba的密码和系统密码默认是分开管理的，需要用smbpasswd命令单独设置。这类问题的本质是"不同的服务有不同的认证源"，排查的时候先搞清楚服务用的是哪套用户体系，别用一套密码去套所有服务。

3.4 VSCode Remote-SSH 连不上的常见原因

VSCode远程开发很爽，但报错信息往往不直观。最常见的两个问题：

第一个是~/.ssh/known_hosts文件冲突。如果服务器的IP或域名以前配过别的密钥，重装系统后指纹变了，SSH客户端会报REMOTE HOST IDENTIFICATION HAS CHANGED。这时候需要删除known_hosts里对应的那一行，然后重新连接。具体操作：

bash复制ssh-keygen -R 你的服务器IP

第二个是VSCode远程服务器端下载依赖失败。VSCode连上服务器之后，需要在服务器端安装一个server组件，如果服务器网络环境不佳（比如无法访问外部下载源），连接会在初始化阶段卡住或报错。这种情况的解决办法是先手动确认服务器能否访问外网，或者配置代理，更省事的方案是先通过命令行SSH连上，再在VSCode里发起连接，有时候把VSCode的remote.SSH.showLoginTerminal选项打开，能看到详细的日志输出，定位会更快。

这些排查思路其实不限于VSCode。任何基于SSH的工具，在报错的时候都可以先去命令行里试一把。命令行是最底层的客户端，如果命令行能连上而工具连不上，那问题大概率出在工具的配置文件上；如果命令行也连不上，就老老实实按链路分层去排查。

3.5 一个完整案例：从超时到定位的逐步排查

讲一个真实的案例。有一次我帮朋友排查一台服务器连不上的问题，他发来的报错是ssh: connect to host xx.xx.xx.xx port 22: Connection timed out。

第一步先ping，通了，说明网络层没问题。第二步telnet xx.xx.xx.xx 22，卡住不动，说明22端口确实不通。第三步去云控制台检查安全组，发现入站规则里只放行了80和443，没有22。于是加上22端口，保存后再试，连接立刻成功。

整个排查过程只有几分钟，但如果一开始就瞎改sshd_config、重启服务器，不仅浪费时间，还可能把原本正常的服务搞挂。这个案例想说的是：排查问题最重要的不是知道答案，而是知道答案在哪一层。每一层的检查方法都很简单，关键是要有顺序地查，而不是乱试。

4. 文件上传工具怎么选：scp、sftp、rsync 的定位与取舍

4.1 最基础：scp 单文件与目录上传

连接问题解决之后，接下来的核心操作就是文件上传。说到上传，很多人第一反应是图形界面拖拽，或者用宝塔面板这种集成工具。但如果你有大量文件需要上传、或者需要自动化处理，命令行工具才是真正的主力。

scp是最直接的上传命令，基于SSH协议，安全性和连接逻辑都和SSH一致。上传单个文件的语法：

bash复制scp /本地路径/文件名 root@服务器IP:/远程路径/

上传整个目录需要加-r参数：

bash复制scp -r /本地目录 root@服务器IP:/远程路径/

指定端口用-P（注意是大写，ssh是小写-p）：

bash复制scp -P 2222 -r /本地目录 root@服务器IP:/远程路径/

scp最大的优点就是简单直接，一条命令搞定，适合小文件、一次性操作。但它也有明显的局限：不支持增量同步，每次都是全量复制，如果文件很大、改动很小，重复上传会浪费大量带宽和时间。另外scp的断点续传支持也很弱，传大文件传了一半断掉了，就只能从头再来。

4.2 交互式传输：sftp 适合临时操作

sftp是SSH协议自带的文件传输协议，它在连接方式上和SSH完全一样。进入交互模式后，可以像操作FTP一样浏览本地和远程目录、上传下载文件。

bash复制sftp root@服务器IP

常用操作：

text复制put 本地文件                 # 上传
put -r 本地目录              # 上传目录
get 远程文件                 # 下载
ls / lls                     # 查看远程/本地目录
cd / lcd                     # 切换远程/本地目录
bye                          # 退出

sftp和scp相比，优势在于交互性，你能先看看远程目录长什么样再决定传到哪里，也支持批量操作部分文件。劣势在于它同样不支持增量同步，适合临时传几个文件、或者远程目录结构不熟悉时需要先探查一下的场景。

4.3 真正的主力：rsync 同步上传

如果你的需求是"把本地文件夹内的所有文件上传到服务器"——这正好是这个项目标题背后最典型的应用场景——rsync才是正确答案。

rsync的核心理念是增量同步。第一次全量传，之后只传变化的部分。文件数量多、单文件大、改动频繁，这些场景rsync都远优于scp和sftp。它还能在传输过程中自动跳过完全相同的文件，节省大量时间。

最基本的用法：

bash复制rsync -avz /本地目录/ root@服务器IP:/远程目录/

这行命令的核心参数：-a是归档模式，保留文件权限、属主、时间戳等属性；-z是传输时压缩，文本类文件效果尤其明显；-v是输出详细信息。默认加-a是好习惯，因为你上传文件通常不只是为了"有个文件在服务器上"，而是希望文件的各种属性也完整保留。

指定端口和密钥的完整写法：

bash复制rsync -avz -e "ssh -p 2222 -i ~/.ssh/id_ed25519" /本地目录/ root@服务器IP:/远程目录/

4.4 场景速查：什么时候用哪个

很多新手有个误区，觉得会用scp就够了。但当你的项目目录里有几万个node_modules文件时，用scp传一次可能要半小时，用rsync几秒钟就能跳过这些没变过的文件。选对工具，体验是数量级的差距。

5. rsync 实战：把整个文件夹安全地同步到服务器

5.1 核心参数拆解：别只会背 -avz

rsync参数非常多，但日常用到的核心参数就那几个，我逐个解释一下，理解了之后就不用死记硬背了。

-a是归档模式，等于-rlptgoD的组合：递归传输目录、保留符号链接、保留权限、保留时间戳、保留属主和属组、保留设备文件。简单理解就是"尽可能让远程文件和本地文件长得一样"。

-z是压缩传输。源文件如果是纯文本、JSON、日志、代码，压缩率很高，传输数据量能减少70%以上。如果是图片、视频、压缩包这种本身已经压缩过的文件，-z反而会消耗CPU，收益不大。所以我一般建议，传代码、配置文件时加-z，传视频、安装包时可以不加。

--progress显示传输进度。同步大目录时建议加上，否则rsync静默工作，你可能都不知道它卡住了还是在正常跑。

-n是dry-run模拟运行，只显示会做什么，不实际执行。这是rsync最适合"试错"的参数，尤其是在加了--delete的场景下。

--delete是让远程目录和本地目录保持完全一致，把本地没有但远程有的文件删除。这个参数很危险，我一般只会配合-n先预演一遍，确认要删的文件都是预料之内的，再真正执行。比如同步网站代码时，本地删掉了一个旧页面，不加--delete的话，服务器上的旧页面还会残留，可能造成安全问题或功能错乱。

5.2 常见实战命令与注意事项

场景一：全量上传一个项目目录到服务器。

bash复制rsync -avz --progress -e "ssh -p 22" ./myproject/ root@服务器IP:/var/www/myproject/

注意源目录末尾的斜杠。加了斜杠，表示把myproject目录内部的内容同步到目标目录；不加斜杠，表示把myproject这个目录本身同步过去。一字之差，目录层级完全不同。这是rsync新手最容易踩的坑。

场景二：排除不需要上传的目录。

bash复制rsync -avz --progress --exclude 'node_modules' --exclude '.git' --exclude 'runtime/cache' ./myproject/ root@服务器IP:/var/www/myproject/

--exclude可以写相对路径，也可以写通配符。把node_modules、.git这种本地依赖或版本库目录排除掉，传输量会小得多。尤其是node_modules，动辄上万个小文件，如果不排除，第一次同步可能要把服务器卡死。

场景三：先预演，再实际同步。

bash复制rsync -avz --delete -n --progress ./myproject/ root@服务器IP:/var/www/myproject/

加上-n跑一遍，看到输出的操作列表，确认无误后去掉-n再执行。这一步花不了几秒钟，但能避免很多灾难性的误删操作。

5.3 大文件传输：断点续传与前台的持久化

rsync虽然支持断点续传，但如果你用的是默认的临时文件机制，中断后重新执行，已经完全传输的部分会被复用，没有传输的部分会继续传，不用从头再来。这比scp优势明显。

不过在执行长任务之前，我还是建议先做两件准备工作。第一，确认终端不会因为空闲而断线。云服务器上SSH连接默认可能有ClientAliveInterval配置，如果空闲超时会断开连接。可以在本地SSH配置中加上ServerAliveInterval 60，每60秒发一个心跳包保持连接。第二，如果传输时间可能超过几小时，直接用tmux或screen把任务挂在后台。

bash复制tmux new -s upload
rsync -avz --progress /大目录/ root@服务器IP:/远程目录/
# 按 Ctrl+b 然后按 d 脱离会话
# 下次进来用 tmux attach -t upload 恢复查看

这样即使本地电脑关机、断网，服务器端的rsync进程也不会中断。我在传输几百GB的数据集时，从来都是tmux起一个会话丢进去，然后该干嘛干嘛，过几个小时回来tmux attach看一眼进度。这个习惯救了我很多次。

5.4 传完之后先别走：校验与验证

很多同学传完文件就以为万事大吉了，实际上文件是否完整、权限是否正确，都需要验证。一个很简单的做法是比对文件数量：

bash复制# 本地
find /本地目录 -type f | wc -l
# 服务器
find /远程目录 -type f | wc -l

如果文件数一致，再抽查几个关键文件的md5值是否一致。对于特别重要的文件（比如数据库备份、配置文件），可以用md5sum或sha256sum做完整性校验：

bash复制# 本地
md5sum /本地目录/config.yaml
# 服务器
md5sum /远程目录/config.yaml

注意rsync本身已经考虑了传输中的校验机制，默认情况下它会比较文件大小和修改时间来决定是否跳过，如果你显式加了-c参数，它还会逐文件计算校验和。如果传完之后hash还是不一致，那就不是传输问题，可能你本地文件本身在传输过程中被改动了（比如边传边写），或者磁盘有问题。这种情况出现的概率很低，但数据安全这个东西，多一道校验总比事后追悔好。

6. 上传完成之后：权限、安全与运维习惯

6.1 权限设置：文件传上去了，能不能用全靠它

文件传到服务器之后，第一件事不是去浏览器里访问，而是确认权限对不对。最常见的场景是网站代码。你把代码上传到/var/www/html，然后发现网页打不开或者报500错误，大概率是文件属主和权限不对。

服务器上跑Web服务的用户通常是www-data（Debian/Ubuntu系）或apache（CentOS系），而你是用root用户把文件传上去的，于是文件的属主是root，Web服务进程没有读取权限，自然就报错了。解决方式就是修改属主：

bash复制chown -R www-data:www-data /var/www/html

上传脚本、配置文件时，还要注意可写权限。一个常见的安全隐患是把上传目录设成了777（所有人可读写执行），这在Web场景下是很危险的做法——攻击者可能通过上传漏洞往这个目录里扔一个可执行脚本，然后直接拿下服务器。所以我的建议是：能不用777就不用，目录给755，文件给644，只有确实需要写操作的特殊目录才单独放开，并且要保证这些目录里不允许执行脚本。

6.2 别忽视时区与时间同步

这个细节可能看起来和文件上传无关，但实际上很影响后续运维。文件上传到服务器后，你用ls -l看到的时间戳如果和本地差了8个小时，说明服务器时区没设置对。不看时间戳还好，一看全是乱的，排查日志的时候就非常痛苦。

查看当前时区：

bash复制timedatectl

如果是UTC时区，改成上海时区：

bash复制timedatectl set-timezone Asia/Shanghai

时间同步方面，Linux服务器默认会通过123端口进行NTP时间同步。Ubuntu/CentOS 7以上系统一般都预装了chrony或systemd-timesyncd，确认一下服务是否在运行即可。这也解释了为什么前面提到的"检查123端口是否关闭"是运维里的高频问题——一旦123端口被防火墙封住，时间同步就失败，服务器时间会慢慢漂移，日志记录、定时任务、证书校验都会出各种莫名其妙的偏差。

6.3 文件上传与服务器安全：守住最后一道防线

服务器安全是一个很大的话题，这里只讲和"文件上传"强相关的两个点。

第一，上传目录的脚本执行权限要严格控制。假设你的网站有一个用户头像上传功能，上传目录是/uploads，那这个目录里最好禁用PHP或任何脚本的执行权限。用Nginx的话，可以做如下配置：

nginx复制location ~* /uploads/.*\.(php|php5|phtml)$ {
    deny all;
}

这样即便攻击者通过上传功能传了一个恶意脚本上来，访问时也会被拒之门外。文件上传漏洞在OWASP的排行里常年靠前，很多漏洞利用工具、靶场（比如CTFHub的web文件上传关卡、Upload-Labs靶场）都在演练这个攻击路径，核心防范原则就是：存储与执行分离——上传的文件只做存储，不赋予执行能力。

第二，定期更新软件包。这句话说出来很老生常谈，但我在实际运维中见过太多因为某个老版本组件存在已知漏洞而被打穿的情况。Ubuntu系系统：

bash复制apt update && apt upgrade -y

CentOS系：

bash复制yum update -y

安全更新没有一劳永逸，只有保持习惯。你上传到服务器的软件、代码、静态文件，本身不会引入漏洞，但它们依赖的运行环境（Web服务器、语言运行时、数据库）才是需要持续关注的部分。

6.4 日常运维的两个好习惯

最后讲两个我在实际使用中觉得非常有用的小习惯，也不局限于连接和上传本身。

第一个是善用~/.ssh/config和别名，把常用的同步命令封装成脚本。比如我本地有一个deploy.sh脚本，每次部署就执行：

bash复制#!/bin/bash
rsync -avz --delete --exclude 'node_modules' --exclude '.git' -e "ssh -p 22" ./ root@ali:/var/www/myproject/
ssh ali "chown -R www-data:www-data /var/www/myproject && systemctl reload php7.4-fpm"

这样一次部署只需要执行一个脚本，连接、上传、权限修正、服务重载全部搞定。

第二个是定期检查服务器登录日志。journalctl -u ssh -f可以看到实时SSH登录记录，或者查看/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS）。正常的话你应该只看到自己的登录记录，如果发现大量来自陌生IP的尝试，那就说明有人在暴力破解你的服务器。这时候除了确认密码登录已关闭，还可以装一个Fail2ban之类的工具，它会自动封禁反复尝试的IP。

我自己在运维服务器时，始终信奉一条原则——不要把服务器当成一次性的玩具，而是当成需要长期维护的生产环境。连接和上传是最基础的操作，但把基础操作做到规范、安全、可自动化，后面的运维工作才会越来越轻松。