本章目标

理解 SSH 的本质和工作原理，掌握基本连接、文件传输、免密登录和配置文件的使用方法。这是你实习第一天就必须能用出来的技能。

实习第一天。

你的 mentor 走过来，丢下一句话："SSH 进 10.0.1.5，把今天的日志拉下来看看。"你点了点头，打开终端，手指悬在键盘上方——然后愣住了。

SSH？那是什么？

如果你现在还不认识这三个字母，这一章就是为你准备的。SSH 是那种学校里几乎不教、但工作中默认你会的东西。更关键的是，它不是某个框架或库——学完 React 你未必需要 Vue，但无论你走前端、后端、运维、数据还是嵌入式，SSH 都会在你职业生涯的某个节点突然出现，并且不会给你预习的时间。

好在 SSH 本身并不复杂。它是那种"10 分钟看懂，一辈子受用"的工具。这一章的目标就是帮你完成这 10 分钟的跨越。

一、SSH 是什么

SSH 全称 Secure Shell。 拆开来看：

• Secure：安全的——你和远程机器之间的所有通信内容都被加密，网络上的中间节点看不到传输的内容
• Shell：壳——操作系统的命令行接口，就是你在前几章一直在用的那个东西

合在一起：SSH 让你在自己的电脑上打开一个终端窗口，但里面运行的 Shell 却属于另一台机器。你输入 ls，列出来的是远程机器的文件列表；你输入 top，看到的是远程机器的 CPU 和内存状态。本地终端变成了远程机器的窗口。

SSH 与远程桌面的区别

Windows 用户可能熟悉"远程桌面"——连接后你能看到远程电脑的整个桌面、图标、窗口。SSH 不同。SSH 只给你一个命令行界面，没有桌面，没有鼠标指针。这意味着 SSH 传输的数据量极小——几 KB 的文字就足以完成一次操作——在网络条件差的环境下也能流畅使用。用手机热点连服务器排查故障，远程桌面会卡到怀疑人生，SSH 则几乎感觉不到延迟。

这也解释了为什么服务器操作系统几乎都不装图形界面：既然管理员只用命令行远程管理，图形界面就是纯粹的资源浪费。

有了 SSH，你就拥有了一种能力：坐在任何地方，操控任何一台你有权限访问的电脑。 你的笔记本、实验室的服务器、云上的虚拟机、家里的树莓派——全部可以通过同一个工具、同一套操作逻辑来管理。命令行不再只是你眼前这台机器的附属品，而是你通往所有机器的通用接口。

二、SSH 的诞生

1995 年，赫尔辛基理工大学

1995 年初，芬兰赫尔辛基理工大学的校园网络遭遇了一次密码嗅探攻击。攻击者在网络设备上安装了数据包截获程序，当用户通过 telnet 或 rlogin 远程登录时，用户名和密码以明文形式在网络中传输，被攻击者完整记录下来。

当时的远程登录工具——telnet、rlogin、rsh——都设计于互联网的"田园时代"，那个年代的开发者默认网络是可信的、用户是善意的。没有人想到要在传输层做加密，因为"谁会去嗅探别人的密码呢？"

这个假设在 1995 年被打碎了。

赫尔辛基理工大学的一位研究员 Tatu Ylonen 决定自己解决问题。他写了一个新工具，核心设计只有一条：所有数据在离开本机之前加密，在到达远程机器之后解密。 网络上的任何中间节点——交换机、路由器、网关——看到的都只是加密后的乱码。他给这个工具起名为 SSH（Secure Shell）。

最初的 SSH 以免费软件形式发布，第一周就获得了数千次下载，覆盖了超过 50 个国家。用户数量远超 Ylonen 的预期——这说明整个互联网都在默默忍受同样的痛苦，只是之前没有人给出解决方案。

随后的故事是开源运动中一个经典的分叉叙事：Ylonen 后来成立了 SSH Communications Security 公司，将 SSH 商业化。作为回应，开源社区从 SSH 1.2.12 的最后一个自由版本 fork 出了 OpenSSH，由 OpenBSD 项目维护至今。如今，OpenSSH 是事实上的标准——Windows 10 以上版本内置的 SSH 客户端就是基于 OpenSSH 实现的。

今天的 SSH 运行在几乎所有需要网络通信的设备上：你的手机（通过 SSH 客户端 App 管理服务器）、你的路由器（通过 SSH 修改配置）、云服务器（SSH 是唯一的管理入口）、物联网设备、甚至某些智能家电的底层调试接口。SSH 早已不是一个"工具"——它和 TCP/IP、DNS、HTTP 一样，是现代互联网的基础设施层级的技术。Ylonen 当初花了一个周末写出来的程序，28 年后仍在支撑着全球数字基础设施的日常运转。

三、基本用法

3.1 连接远程机器

最基础的 SSH 命令：

ssh user@host

• user：你在远程机器上的用户名
• host：远程机器的地址，可以是 IP 地址（如 192.168.1.100）或域名（如 myserver.example.com）

一个真实例子：

ssh chenxu@10.0.1.5

这行命令的意思是：以用户 chenxu 的身份，连接到 IP 地址为 10.0.1.5 的机器。连接成功后，你的终端提示符会变成远程机器的提示符——你输入的任何命令都将在远程机器上执行。

如果远程机器的 SSH 服务运行在非默认端口（默认是 22），用 -p 参数指定：

ssh -p 2222 chenxu@10.0.1.5

端口号通常由服务器管理员设定。22 是 SSH 的默认端口，但很多服务器出于安全考虑会改用其他端口——就像你家不一定非要用 80 号门牌。

3.2 第一次连接的指纹验证

当你第一次连接一台新机器时，会看到类似这样的提示：

The authenticity of host '10.0.1.5 (10.0.1.5)' can't be established.
ED25519 key fingerprint is SHA256:gwuKhCPlEjNx4iFPVb2zFhDxHymCzBvLqkY6nGexN8M.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

这个提示的意思是：SSH 客户端从来没连接过这台机器，无法确认它的身份。它给你看了一个指纹（fingerprint）——由远程机器的公钥经过哈希计算得到的一串字符——让你人工判断"这台机器是不是你要连的那台"。

这是一个关键的安全机制。想象一下：如果有人在你的网络路径上伪造了一台假的服务器，它的 IP 地址和你真正的服务器一模一样，你就可能在不知情的情况下把密码发给攻击者。指纹验证就是为了阻止这类"中间人攻击"。

指纹验证实操指南

在实际工作中，服务器管理员通常会通过另一条安全渠道（内部文档、工单系统、当面告知）把指纹发给你。你对比终端上显示的指纹和记录中的指纹——一致就输入 yes，不一致就拒绝连接并报告安全事件。

如果你用的是云服务（AWS、阿里云等），控制台页面通常也会显示实例的 SSH 指纹供核对。

输入 yes 后，远程机器的指纹会被存入 ~/.ssh/known_hosts 文件。以后每次连接同一台机器，SSH 都会自动核对指纹——如果某一天指纹突然变了，SSH 会发出安全警报并拒绝连接。这不是 bug，是 SSH 在保护你。

3.3 断开连接

完成后，用以下任一方式断开：

exit

或者按 Ctrl + D（发送 EOF 信号，告诉 Shell "对话结束"）。

四、传输文件

连接服务器只是第一步。你经常需要把文件传上去——部署代码、上传配置、拉取日志备份——或者从服务器下载数据到本地。SSH 生态提供了两个核心工具来完成这些任务。

4.1 scp：安全的文件拷贝

scp（Secure Copy）是 SSH 协议的文件传输工具。语法和你熟悉的 cp 几乎一样，只是源或目标地址可以带有远程前缀。

从本地上传到远程：

scp file.txt chenxu@10.0.1.5:/home/chenxu/

把当前目录的 file.txt 复制到远程机器 10.0.1.5 的 /home/chenxu/ 目录下。

从远程下载到本地：

scp chenxu@10.0.1.5:/var/log/app.log ./

把远程机器的 /var/log/app.log 文件下载到本地当前目录。注意末尾的 ./ 表示当前目录。

复制整个目录（递归）：

scp -r project/ chenxu@10.0.1.5:/home/chenxu/

-r（recursive）参数递归复制整个 project/ 文件夹。部署项目时这个命令用得非常频繁。

指定端口（如果远程 SSH 服务不在默认 22 端口）：

scp -P 2222 file.txt chenxu@10.0.1.5:/home/chenxu/

scp 的端口参数是大写的 -P

SSH 使用 -p（小写）指定端口，但 scp 使用 -P（大写）。这是历史遗留的不一致——scp 的 -p 已被"保留文件属性（preserve）"占用了。每次在 ssh 和 scp 之间切换时，端口参数的大小写是最容易被绊倒的坑。

4.2 rsync：更聪明的同步工具

scp 简单直接，但有一个明显的不足：每次运行都会重新传输所有文件，即使目标机器上已经有一份完全相同的副本。对于大项目来说，这意味着大量不必要的数据传输。

rsync 解决了这个问题。它只传输发生变化的部分：

rsync -avz project/ chenxu@10.0.1.5:/home/chenxu/project/

三个参数的含义：

• -a（archive）：归档模式，保留文件权限、时间戳等元信息，递归复制目录
• -v（verbose）：显示传输进度
• -z（compress）：传输过程中压缩数据，减少网络流量

第二次运行同样的命令时，rsync 会比较本地和远程文件的差异，只传输修改过的部分。对于一个 500MB 的项目，如果只改了一行代码，scp 会重新传输 500MB，rsync 只传输几 KB。

scp vs rsync 的选择建议

• 一次性传几个小文件 → 用 scp，命令简短
• 定期同步项目/目录 → 用 rsync，增量传输节省时间
• 不太确定 → 先用 scp，等你觉得"每次都全量传输太慢了"的时候，自然会想学 rsync

rsync 的功能远不止这里介绍的——它可以做本地同步、远程备份、断点续传。把 rsync 的 man 页面作为"等有空了再看"的储备知识即可。

五、免密登录

每次 SSH 连接都输入密码，3 次之后就会开始烦躁。更关键的是，密码登录在安全层面有两个天然缺陷：密码可能被暴力破解，密码可能在网络传输中被窃取（即使 SSH 加密了传输内容，弱密码本身仍然容易被猜中）。

SSH 的解决方案是密钥对认证——一套同时解决了便捷性和安全性的机制。

密钥对认证的原理

密钥对包含两个文件：私钥和公钥。它们是一对数学上关联的字符串，但具有一个关键的不对称性：公钥可以公开给任何人，私钥必须永远保密。

认证的过程如下：

1. 你把公钥放在远程服务器的 ~/.ssh/authorized_keys 文件中
2. 连接时，服务器用你的公钥加密一个随机字符串，发回给你
3. 你的 SSH 客户端用私钥解密这个字符串，发回给服务器
4. 服务器验证解密结果正确——只有持有对应私钥的人才能完成这一步——认证通过

整个过程不涉及密码明文，私钥也从未离开过你的机器。攻击者即使截获了网络数据包，拿到的只是一个用公钥加密的随机数——没有私钥，无法解密，攻击无意义。

为什么密钥比密码更安全

一个 12 位的随机密码也许有 70 位熵（信息论中衡量随机性的单位，越高的熵值意味着越难被暴力穷举）。一个 ed25519 密钥有 128 位安全强度。更重要的是，密码可以被钓鱼、被键盘记录器截获、被重复使用在多个服务上。密钥文件 4096 位长，保存在本地磁盘，永不离开你的机器。攻击者要破解它，不是猜密码——而是正面挑战椭圆曲线密码学的数学难题。

5.1 生成密钥对

ssh-keygen -t ed25519 -C "your_email@example.com"

参数说明：

• -t ed25519：指定密钥类型为 Ed25519——一种现代椭圆曲线算法。比老式的 RSA 更安全、更紧凑、计算更快。除非要兼容极老旧的服务器（2014 年以前的系统），否则永远用 ed25519。
• -C "your_email@example.com"：添加一个注释，方便辨识这个密钥的用途。用你的邮箱即可。

执行后，程序会询问：

• 密钥保存位置：直接回车，使用默认路径 ~/.ssh/id_ed25519
• 密码短语（passphrase）：可选，如果设置，每次使用私钥时都需要输入。多一层保护——即使私钥文件被盗，没有 passphrase 也无法使用

生成成功后，~/.ssh/ 目录下多了两个文件：

• id_ed25519 —— 私钥。这是你必须保护的秘密，权限应为 600（仅所有者可读写）
• id_ed25519.pub —— 公钥。这个可以分发给任何你需要登录的服务器

5.2 把公钥放到服务器上

ssh-copy-id 一条命令完成：

ssh-copy-id chenxu@10.0.1.5

这条命令会自动将你的公钥追加到远程服务器 ~/.ssh/authorized_keys 文件中。之后你就可以免密登录了：

ssh chenxu@10.0.1.5
# 直接进入，无需密码

如果服务器不支持 ssh-copy-id（极少数情况），手动操作等价于：

cat ~/.ssh/id_ed25519.pub | ssh chenxu@10.0.1.5 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

私钥，永远不离开你的机器

一个常见的错误认知是"把密钥对的两个文件都发给服务器"。不对。私钥是你的数字身份证，应该像对待实体身份证一样保护它。公钥可以随便分发——它本来就是设计为公开的。从数学上讲，从公钥推导出私钥在计算上是不可行的（这也是"非对称加密"这个名字的由来）。但如果私钥文件本身泄露了，整个安全模型就崩溃了。

六、SSH 配置文件

当你开始管理多台服务器时——实验室的 GPU 工作站、云上的开发机、家里的树莓派、实习公司的跳板机——你会发现自己反复输入各种 IP 地址和参数。每台机器的用户名不同，端口号不同，密钥文件也不同。ctrl+r 翻历史命令很快就不够用了。

SSH 的解决方案是一个配置文件：~/.ssh/config。

6.1 基本配置

在这个文件中，你可以给每台机器定义一个简短的别名：

Host myserver
    HostName 192.168.1.100
    User deploy
    Port 2222
    IdentityFile ~/.ssh/my_key

保存后，原本需要这样输入的完整命令：

ssh -p 2222 -i ~/.ssh/my_key deploy@192.168.1.100

现在只需：

ssh myserver

scp 和 rsync 也会识别这个配置——它们都读取 ~/.ssh/config：

scp file.txt myserver:/home/deploy/

6.2 多台服务器配置示例

配置文件支持任意数量的条目，你可以给它们取任何有意义的名字：

# 实习公司的开发服务器
Host company-dev
    HostName 10.0.1.5
    User chenxu
    IdentityFile ~/.ssh/company_key

# 阿里云上的个人项目
Host mycloud
    HostName 47.96.xxx.xxx
    User root
    Port 2222
    IdentityFile ~/.ssh/aliyun_key

# 实验室的 GPU 服务器（需要经过跳板机）
Host lab-gpu
    HostName 192.168.100.50
    User student
    ProxyJump lab-gateway

Host lab-gateway
    HostName lab.university.edu.cn
    User student

配置文件让一切变简单

当你只有一台服务器时，配置文件看起来是多余的。当你有 5 台时，它开始变得有用。当你有 10 台以上时，没有它在各个 IP 地址和端口号之间跳转会非常痛苦。

配置文件的真正价值并非省打字时间，而是消除认知负担。你不用记住10.0.1.5 是开发环境还是生产环境，deploy 用户的端口是 2222 还是 2223——这些细节全部封装在别名里，你的大脑只需要记住有意义的名称。

6.3 常用配置选项

选项	含义	示例
HostName	远程机器地址	192.168.1.100 或 myserver.com
User	登录用户名	deploy
Port	SSH 端口	2222
IdentityFile	私钥文件路径	~/.ssh/my_key
ProxyJump	跳板机（中间代理）	gateway
ServerAliveInterval	心跳间隔（秒），防止空闲断连	60
Compression	是否压缩传输（yes/no）	yes

ServerAliveInterval 的作用

有些服务器的防火墙会在一段时间无数据交互后自动断开空闲连接。你在终端里看起来一切正常，但几秒钟后输入的命令完全没有回应——连接已经死了，只是你的终端还不知道。

ServerAliveInterval 60 让 SSH 客户端每 60 秒自动向服务器发送一个心跳包。这不仅告诉防火墙"这条连接还活着"，也让客户端能更快地发现连接已经断开（而不是等到你输入下一条命令时才发现）。对于需要长时间保持连接的工作（比如在服务器上跑一个持续数小时的训练脚本），这个参数极为实用。

七、实习和校园里的真实场景

你会在这四个场景中第一次用到 SSH

场景一：连接大学实验室的服务器

很多大学为计算机专业的学生提供 Linux 服务器用于课程实验——大数据处理、深度学习训练、编译大型项目。这些服务器通常只开放 SSH 访问：

ssh student@cs-lab.university.edu.cn

你不需要去机房，不需要插显示器。在宿舍的笔记本上写好代码，scp 上传到实验室服务器，用服务器的 64 核 CPU 和 4 块 GPU 跑训练——这才是大学计算资源的正确打开方式。

场景二：把你的课程项目部署到云服务器

买了一台阿里云 / AWS / 腾讯云的虚拟机，IP 是 47.96.xxx.xxx。怎么把代码传上去？

# 1. 生成密钥对
ssh-keygen -t ed25519

# 2. 把公钥添加到云服务器（控制台通常也支持界面导入）
ssh-copy-id root@47.96.xxx.xxx

# 3. 上传项目
scp -r my-project/ root@47.96.xxx.xxx:/opt/

# 4. 登进去启动服务
ssh root@47.96.xxx.xxx
cd /opt/my-project
npm start

场景三：拉取生产日志排查 bug

这是实习中最典型的 SSH 使用场景。你的 mentor 告诉你"用户反馈登录失败，去查一下今天的登录日志"：

ssh deploy@10.0.1.5
tail -n 500 /var/log/app/auth.log | grep "login failed"

你坐在自己的工位上，用自己电脑的终端，操作着远在机房里的服务器。在命令行里，距离只是一行命令的事。

场景四：连接本地网络的树莓派

很多同学的硬件课设中使用树莓派作为控制核心。与其给树莓派单独接一套键盘鼠标显示器，不如直接 SSH 进去：

ssh pi@raspberrypi.local

树莓派接一根电源线和一根网线就够了。开发、调试、部署全部通过 SSH 完成。一块巴掌大的开发板变成了一个可以远程操控的完整 Linux 环境。

八、SSH 是基础设施

没有 SSH 的世界

如果没有 SSH，以下事情今天都无法做到——至少无法以现在的方式做到：

• 远程服务器管理：管理员需要亲自走进机房，插上显示器和键盘，或者使用不加密的 telnet 把 root 密码暴露在网络中
• 云计算：AWS、Azure、阿里云的所有虚拟机实例的管理入口都是 SSH。没有 SSH，云计算的运维模型将完全不同
• CI/CD 流水线：GitHub Actions、Jenkins、GitLab CI 在部署步骤中通过 SSH 连接生产服务器，执行更新命令。这是一切自动化部署的最后一公里
• Git over SSH：每次 git push 和 git pull，如果使用 SSH 协议的远程地址（git@github.com:user/repo.git），底层传输用的正是 SSH 协议
• 容器编排：Kubernetes 节点管理、Docker 远程守护进程——背后的连接通道几乎都是 SSH

SSH 属于那一类技术：你平时完全感觉不到它的存在，但把它抽走，整个数字世界会在几秒钟内坍塌。它和 DNS、TCP、HTTP 处于同一个层级——并非你每天手动调用的工具，而是支撑着你每天调用的所有工具的底层支柱。

这不是夸大。试着想象：公司所有的服务器都在一个没有 SSH 的世界里。部署代码需要运维人员走进机房，用 U 盘或者移动硬盘手动覆盖文件。服务器报错需要程序员亲自到机房看日志。发布一个版本需要协调十几个人的物理位置。互联网公司的"快速迭代"在物理距离面前完全瓦解。SSH 解决的不仅是"怎么远程登录"，而是一个更深层的问题：人和机器之间的物理距离，不应该成为操作能力的边界。

九、安全注意事项

必须遵守的底线

1. 永远不要分享你的私钥文件。

私钥是你的数字身份凭证。任何拥有你私钥的人都可以以你的身份登录所有你已经配置了对应公钥的服务器。不要把私钥传到 Git 仓库（.gitignore 中务必加入 *_rsa、*_ed25519 等常见私钥模式）。不要通过微信、QQ、邮件发送私钥文件。如果你需要给别人访问服务器的权限，让他们自己生成一对密钥，你把公钥加入 authorized_keys。

2. 使用 ed25519 密钥类型。

Ed25519 是目前推荐的密钥算法。比 RSA 更安全（128 位安全强度，RSA 2048 约等于 112 位），密钥文件更短（Ed25519 私钥约 400 字节，RSA 4096 私钥约 3.2KB），签名和验证速度更快。除非你的目标服务器运行的是 2014 年之前的 OpenSSH 版本（几乎不会遇到），否则一律用 ed25519。

3. 在你的服务器上禁用密码登录。

密钥认证配置好之后，关闭密码登录是提高服务器安全性效果最立竿见影的操作：

# /etc/ssh/sshd_config
PasswordAuthentication no

修改后重启 SSH 服务：sudo systemctl restart sshd。

这行配置的效果是：即使攻击者猜到了 root 密码，也无法登录——因为没有密钥文件，认证阶段就直接拒绝。互联网上每时每刻都有无数自动化脚本在扫描 22 端口，尝试常见的用户名密码组合。关闭密码登录意味着这些攻击在你的服务器面前彻底失效。

4. 正视指纹警告。

第一次连接时出现指纹提示是正常的——SSH 没有这台机器的记录，需要你人工确认。但如果一台你之前连过很多次的机器突然弹出指纹警告，说明 SSH 检测到了异常：

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

这可能意味着服务器重装了系统（正常情况），也可能意味着有人在试图劫持你的连接（攻击行为）。不要习惯性地无视这个警告。花 10 秒钟确认原因。如果确认是正常的系统重装导致指纹变更，删除旧指纹记录即可：

ssh-keygen -R 10.0.1.5

如果是你不知道原因的指纹变化——联系服务器管理员，不要强行连接。

22 号端口是互联网上扫描量最大的端口

不夸张地说，一台开放了 22 端口且允许密码登录的新服务器，通常在上线后几分钟内就会开始收到来自全球各地的暴力破解尝试。这不是因为你被盯上了——是全球范围内有大量自动化扫描脚本在 7x24 小时持续探测整个 IPv4 地址空间的 22 号端口。你只是恰好轮到了。

解决方案就是本节第 3 条：配置好密钥认证之后立刻关闭密码登录。这不是可选的"安全加固"，是 2026 年任何面向公网的 SSH 服务都必须执行的基本配置。

十、本章小结

1. SSH 让你在本地操作远程机器 —— 你输入命令，在远程执行，结果返回你的屏幕。网络中间传输的一切内容都是加密的
2. ssh user@host 是基本连接命令 —— -p 指定端口。第一次连接时会出现指纹验证，这是安全机制，不是错误
3. scp 和 rsync 负责文件传输 —— scp 简单直接，rsync 增量同步更高效。两者都走 SSH 协议，继承了 SSH 的加密保护
4. 密钥认证比密码更安全也更方便 —— ssh-keygen -t ed25519 生成密钥对，ssh-copy-id 部署公钥。私钥永远不离开你的机器
5. ~/.ssh/config 是管理多台服务器的标准方式 —— 给每台机器起一个有意义的名字，告别反复输入 IP 和端口号的痛苦
6. SSH 不只是一个工具，它是互联网基础设施 —— 没有 SSH，就没有现代云计算、没有 CI/CD、没有 Git over SSH。它的影响力远超它表面的简单

动手任务

基础练习：

1. 确认你的系统中有 SSH

   ssh -V
   # 应该输出 OpenSSH 的版本信息

2. 生成你的第一对密钥

   ssh-keygen -t ed25519 -C "my_first_key"
   # 一路回车使用默认设置
   ls -la ~/.ssh/
   # 你应该看到 id_ed25519（私钥）和 id_ed25519.pub（公钥）

3. 查看你的公钥内容

   cat ~/.ssh/id_ed25519.pub

   这就是你将来要放到远程服务器上的内容。

需要一台远程机器的练习：

4. 连接一台远程服务器（如果你有的话——云服务器、实验室机器、树莓派均可）

   ssh user@your-server-ip

5. 配置免密登录

   ssh-copy-id user@your-server-ip
   # 之后直接 ssh user@your-server-ip，无需密码

6. 传输一个文件

   echo "hello from local" > test.txt
   scp test.txt user@your-server-ip:~/
   ssh user@your-server-ip "cat ~/test.txt"
   # 在远程机器上看到了你从本地传过去的文件

7. 创建你的第一个 SSH 配置文件 在 ~/.ssh/config 中添加一条记录，然后尝试用别名连接：

   ssh myserver   # 不再是 ssh -p 2222 -i ~/.ssh/key user@192.168.1.100

如果手头没有远程机器：

• 使用云服务商的免费试用方案（AWS Free Tier、阿里云试用等）创建一台虚拟机
• 在本地安装一个 Linux 虚拟机（VirtualBox + Ubuntu），配置 SSH 后从宿主机连接
• 开启 Windows 自带的 OpenSSH Server（设置 → 应用 → 可选功能 → 添加 OpenSSH 服务器），然后 ssh username@localhost ——自己连自己也算练习

---

下一章：脚本入门 →

在下一章，我们将学习如何把多条命令组合成脚本，让电脑自动完成重复任务——这是命令行的终极生产力形态。