[ssh-sftp]解决ssh协议-避坑ssh和sftp的配置

whoway2026/1/16大约 10 分钟

[ssh-sftp]解决ssh协议-避坑ssh和sftp的配置

场景1：修改ssh和sftp的默认端口

底层原理：ssh获取配置数据的顺序【3步骤】

ssh 可以从用户级配置文件和系统级配置文件中获取更多的配置数据，这样我们可以在使用ssh时省掉很多繁杂的命令选项。

使用ssh命令进行远程登录时，实际上可以不使用-p选项显示指明端口，我们可以通过配置文件的方式来设置ssh命令默认端口。

实际上ssh获取配置数据会以下面的顺序进行：

1.command-line options
2.user's configuration file【用户的配置文件】 (~/.ssh/config)
3.system-wide configuration file【全系统配置文件】 (/etc/ssh/ssh_config)

所以，我们的ssh服务端程序建议修改：/etc/ssh/ssh_config

因此更改配置文件
~/.ssh/config
或
/etc/ssh/ssh_config
的Port选项即可

关于ssh客户端配置文件的内容说明，具体参见ssh_config(5)，使用命令man 5 ssh_config即可打开。

1、登录服务器，【root权限】-打开sshd_config文件

vim /etc/ssh/sshd_config

2、找到`#Port 22`

默认是注释掉的，先把前面的#号去掉，**再插入一行设置成你想要的端口号，注意不要跟现有端口号重复，**比如下面改为10022

......

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
# Port 22
Port 10022
.....

SSH默认监听端口是22，如果你不强制说明别的端口，”Port 22”注不注释都是开放22访问端口！

如上：我增加了10022端口，大家修改端口时候最好挑10000~65535之间的端口号

10000以下容易被系统或一些特殊软件占用，或是以后新应用准备占用该端口的时候，却被你先占用了，导致软件无法运行。

3、重启SSH服务，最好也重启下服务器

更改配置文件后，我们需要激活新配置。

我们应该重新启动SSH服务，它将重新读取配置文件并使用新的SFTP端口号。

systemctl restart sshd  
shutdown -r now

尝试通过10022端口登录SSH，或者进入该服务器直接本地访问SSH如下：

ssh root@localhost -p 10022

场景2：ssh公钥认证是ssh认证的方式之一，通过公钥认证可实现 ssh 免密码登陆

收益：解决vscode、ssh、xshell免密登录！

【坑】2个命令ssh-keygen和ssh-copy-id

底层原理：客户端ssh把自己生成的.pub公钥注册到服务器端ssh的authorized_keys文件中

某个ssh客户端，使用客户端机器上的**~/.ssh/id_rsa**这个默认的私钥

~/.ssh/id_rsa        （私钥，只能你自己有）
~/.ssh/id_rsa.pub    （公钥，可以公开）

# 把客户端的~/.ssh/id_rsa.pub公钥打印出来，然后放到ssh服务器的下面文件里面：
~/.ssh/authorized_keys

ssh公钥免密登录的认证流程：证明“我这个客户端有私钥”，而不是“我给你私钥”

登录时发生了什么：
① 客户端说：“我想用公钥方式认证，这是我的公钥指纹【是按照我自己登录你指定的那个pub文件，比如~/.ssh/id_rsa.pub生成的】”
② 服务器做两件事：
检查：这个公钥 在不在 authorized_keys
如果在 → 生成一个 随机挑战（challenge）
③ 服务器发送 challenge 给客户端
这是一个随机字符串（一次性的）
④ 客户端用 私钥 做什么？【我使用我自己指定的私钥：~/.ssh/id_rsa】所以才有ssh whoway@code.whoway.xyz -p 12345 -i ~/.ssh/id_rsa_dev_aliyun 这种写法
用私钥对 challenge 签名
signature = sign(challenge, private_key)
⑤ 客户端把签名发回服务器
⑥ 服务器用 公钥验证签名
verify(signature, challenge, public_key)
✔ 能验证成功 → 你确实拥有私钥
❌ 验证失败 → 拒绝登录

视角1：本地ssh作为客户端连接别人，目标：使用`ssh-keygen`指定某个备注的后缀，然后使用`~/.ssh/config`给不同ssh服务器配置不同的本地.pub文件

ssh-keygen -t rsa -C "111" -f ~/.ssh/id_rsa_whoway

ssh-keygen -t rsa -C "whoway@baidu.com" -f ~/.ssh/id_rsa_whoway

ssh-keygen -t rsa -C "whoway1@baidu.com" -f ~/.ssh/id_rsa_github

ssh-keygen -t rsa -C "whoway2@baidu.com" -f ~/.ssh/id_rsa_gitee

【但是这样引入了一个问题！】那就是默认我们只会用id_rsa这个私钥；

确实，当生成多个 SSH 密钥对时，默认的私钥文件 ~/.ssh/id_rsa 会被优先使用，这可能导致新生成的密钥对（如 ~/.ssh/id_rsa_whoway）无法直接被用到。但可以通过以下方法解决。所以才有一个东西【config文件】

修改 SSH 配置文件 ~/.ssh/config

为不同的主机指定对应的私钥文件，避免冲突。

Host myserver
    HostName remote-server.com
    User your-username
    IdentityFile ~/.ssh/id_rsa_whoway

这样设置后【理论上确实是ok的】

但是我后边发现还是有问题。

确实很神奇！~/.ssh/config 的权限问题经常是 SSH 配置出错的一个常见原因。

==如果 ~/.ssh/config 文件的权限设置不正确，SSH 客户端可能会忽略或无法读取该文件，从而导致配置无效或连接问题==。

比如，在公司，我就遇到了对应的原因，导致我go mod tidy总是不ok

解决方案：避坑，客户端ssh的`~/.ssh`和`~/.ssh/config`的权限要对！

SSH 要求用户家目录和 ~/.ssh 目录不能被“其他人或组写”，否则公钥认证会被直接拒绝（防止别人往你的 .ssh 目录里“偷偷塞公钥或改配置”，从而冒充你登录）

OpenSSH 的态度是：只要存在“理论上可能被别人篡改密钥的风险”，就直接拒绝使用这些文件

chmod 700 ~/.ssh
chmod 600 ~/.ssh/config

是的，你没看错。。我也发现我原本这2个文件的权限其实也是这个,但是。。。就是还是要执行一下才ok，我也不知道原因【可能是linux本身的bug吗}，我机器的linux内核是6.3版本

配置好后就可以开心的，借助本地的私钥，去在终端登录

比如：

# 使用别名去登录
alias aliyun="ssh whoway@code.whoway.xyz -p 12345 -i ~/.ssh/id_rsa_dev_aliyun"

视角2：本地ssh是作为服务器端：修改自`己的~/.ssh/authorized_keys`去承接你要接收的客户端的.pub文件的内容！

在 ~/.ssh/authorized_keys 文件里，每一行代表一个.pub公钥

除了公钥本身，你完全可以在行尾加注释，也可以在单独一行前面加 # 来注释整行：

# 开发机A的key Windows
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC3... user1@host   
# 小王的MacBook
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKh... user2@laptop

注意：

公钥部分（ssh-rsa 或 ssh-ed25519 开头直到邮箱/标识符结束）中间不能乱加注释或换行，否则解析失败

总结：客户端的.pub公钥放到服务器的`~/.ssh/authorized_keys`下，客户端的vscode、ssh命令行、xmobaxterm啥的那个验证文件都是本地的`~/.ssh/id``rsa``_公钥`

一般叫：验证文件
IdentityFile

场景3：开启并使用 SSH 连接复用（Connection Multiplexing），让你多次 SSH 到同一台服务器时更快、不用重复建连接

修改

Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p
	ControlPersist yes 
	ServerAliveInterval 60
	PubkeyAcceptedAlgorithms +ssh-rsa
	HostkeyAlgorithms +ssh-rsa	
Host relay.demo.xyz
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p
	ControlPersist yes 
	ServerAliveInterval 60
	PubkeyAcceptedAlgorithms +ssh-rsa
	HostkeyAlgorithms +ssh-rsa

前3个配置最有用！

【1】ControlMaster auto意思是：自动启用“主连接（Master Connection）”
第一次 SSH 连接到某台服务器时：
- 建立一个“主连接”
之后再 SSH 到同一台服务器：
- 复用这个已有连接
- 不再重新握手、认证

效果：连接速度明显更快、不用每次都输密码 / 再次用密钥验证

【2】ControlPath ~/.ssh/master-%r@%h:%p

意思是：指定“主连接”的控制 socket 文件保存路径

这个路径里用了占位符：

占位符	含义
`%r`	远程用户名（remote user）
`%h`	主机名（host）
`%p`	端口（port）

比如你执行：

ssh user@192.168.1.10 -p 22

实际生成的控制文件可能是：

~/.ssh/master-user@192.168.1.10:22

这个文件就是连接复用的“钥匙”

总体效果一句话总结

👉 让 SSH 连接可以复用，提升速度，减少重复认证

非常适合：

经常 ssh / scp / rsync
运维、开发、跳板机
使用 Ansible、Fabric 等工具
ControlPersist yes
永久保持（直到：
- SSH 进程被杀、机器重启、手动关闭

适合：你频繁 SSH 同一批机器、本地机器长期不关机、开发 / 运维环境

ControlPersist 10m（或 `600`）
# *定时保持，**空闲 10 分钟后自动关闭

场景4：ssh隧道【对付堡垒机、跳板机】ProxyJump

需要 OpenSSH 7.3 以上版本才可以使用 ProxyJump, 相对 ProxyCommand 更简洁方便些

https://plantegg.github.io/2019/06/02/史上最全_SSH_暗黑技巧详解--收藏保平安/

内部堡垒机、跳板机都需要密码+动态码，太复杂了，怎么解？
$ cat ~/.ssh/config 
#reuse the same connection --关键配置
ControlMaster auto
ControlPath ~/tmp/ssh_mux_%h_%p_%r

#查了下ControlPersist是在OpenSSH5.6加入的，5.3还不支持
#不支持的话直接把这行删了，不影响功能
#keep one connection in 72hour
#ControlPersist 72h
#复用连接的配置到这里，后面的配置与复用无关

#其它也很有用的配置
GSSAPIAuthentication=no
#这个配置在公网因为安全原因请谨慎关闭
StrictHostKeyChecking=no
TCPKeepAlive=yes
CheckHostIP=no
# "ServerAliveInterval [seconds]" configuration in the SSH configuration so that your ssh client sends a "dummy packet" on a regular interval so that the router thinks that the connection is active even if it's particularly quiet
ServerAliveInterval=15
#ServerAliveCountMax=6
ForwardAgent=yes

UserKnownHostsFile /dev/null
在你的ssh配置文件增加上述参数，意味着72小时内登录同一台跳板机只有第一次需要输入密码，以后都是重用之前的连接，所以也就不再需要输入密码了。

借助跳板机

# 跳板机
Host bastion
    HostName 1.2.3.4
    User jumpuser

Host work
    HostName 10.10.0.8
    User dev
    ProxyJump bastion

附录1、windows电脑还有个同时使用的xmobaxterm的天坑

# Read more about SSH config files: https://linux.die.net/man/5/ssh_config
Host 阿里云whoway
    HostName 111.51.10.114
    User whoway
    # 我怀疑，还要密码，是因为这是mobaxterm的原因，可能windows也要在~/.ssh的才行
    # 下面2个都不行，只有那个真正的~/.ssh下的才行，感觉是读取windows的~而不是mobaxterm的bash.exe的~/
    # IdentityFile "C:\Users\whowa\appdata\roaming\mobaxterm\home\.ssh\id_rsa_aliyun"
    # IdentityFile "C:\Users\whowa\appdata\roaming\mobaxterm\home\.ssh\id_ed25519"
    IdentityFile "C:\Users\whowa\.ssh\id_ed25519"
    Port 123456

附录2、ssh隧道和http隧道的区别

用途和协议：

SSH隧道：基于SSH协议，用于安全地传输任何TCP连接。它可以用于访问受限制的服务或通过不安全的网络（如公共WiFi）安全地传输数据。SSH隧道通常用于远程访问、文件传输和加密通信。
HTTP隧道：基于HTTP协议，通常用于通过HTTP代理访问内部网络或绕过防火墙限制。HTTP隧道允许将非HTTP流量伪装为HTTP流量，通常用于代理服务器和访问控制。
实现方式：
SSH隧道：通过在客户端和服务器之间建立安全的SSH连接，隧道可以传输各种类型的数据。SSH隧道使用SSH客户端和服务器的端口来进行通信。
HTTP隧道：使用HTTP协议进行通信，将非HTTP流量封装在HTTP请求和响应中。这种方式使得非HTTP流量能够通过HTTP代理服务器进行传输。
安全性和使用场景：
SSH隧道：提供了较高的安全性，数据在传输过程中被加密。常用于需要保护数据完整性和隐私的场景，如远程登录和安全文件传输。
HTTP隧道：通常安全性较低，因为HTTP本身并不对传输的数据进行加密。主要用于绕过网络限制和访问控制，但不适合对数据传输安全性要求较高的场合。

综上所述，选择使用SSH隧道还是HTTP隧道取决于具体的安全需求和数据传输场景。SSH隧道适合需要高安全性和数据完整性的情况，而HTTP隧道则适合需要通过代理绕过网络限制的情况。

参考资料

https://help.aliyun.com/zh/ecs/user-guide/instance-logon-credential-management?spm=5176.10483814.console-base_help.dexternal.2c40e651b7dCNt#dcf130226ceuy