一、你的SSH连接失败核心原因 #

你现在遇到的问题，本质是连接错了服务端口+验证机制不匹配：

1. 你执行的命令ssh -p 22 -Tvv git@***.***.***.***是连接服务器的系统SSH服务（sshd，默认22端口），但你在Gitea用户设置里添加的公钥，是存在Gitea数据库里的——系统sshd的git用户根本看不到这些公钥，自然会拒绝你的公钥验证，转而要求密码。
2. 之前用GitLab正常，是因为GitLab默认会接管或监听22端口，它的SSH服务直接对接自己的用户公钥体系；但Gitea默认不会这么做，它的SSH服务通常用独立端口（比如默认2222），和系统sshd分开。

二、快速解决方案 #

方案1：用Gitea默认SSH端口连接

先确认你的Gitea SSH服务端口（默认是2222，可在Gitea后台「站点管理→配置」里查看），然后执行：

ssh -p 2222 -Tvv git@***.***.***.***

这个命令会直接连接Gitea自带的SSH服务，它会读取你在Gitea用户设置里添加的公钥，验证通过后就能正常返回Gitea的欢迎信息。

方案2：让Gitea监听22端口（替代系统sshd）

如果你习惯用22端口连接，需要修改Gitea的配置文件：

1. 找到Gitea的配置文件（通常在/etc/gitea/app.ini，或你的Gitea安装目录下）
2. 修改[server]区块的配置：

[server]
SSH_PORT = 22          # 对外暴露的SSH端口
SSH_LISTEN_PORT = 22   # Gitea内部监听的SSH端口

3. 重启Gitea服务：

sudo systemctl restart gitea  # 如果你用systemd管理服务
# 或者用你对应的启动命令，比如./gitea restart

注意：修改前要确保系统的sshd服务已经停止，避免端口冲突。

三、额外检查点 #

• 确认你本地的私钥（C:\Users\client/.ssh/id_rsa）和Gitea里添加的公钥是一对——可以在本地执行ssh-keygen -l -f ~/.ssh/id_rsa.pub，对比输出的指纹和Gitea里显示的公钥指纹是否一致。

ssh git@xxx 和 ssh root@xxx 的核心差异 #

这两个命令的本质是登录服务器的不同用户，差异非常大：

• 身份与权限：
  • ssh root@xxx登录的是服务器的超级管理员root用户，拥有服务器的所有权限，可以修改任何文件、安装软件、管理其他用户。
  • ssh git@xxx登录的是专门用于Git操作的用户（如果是Gitea的SSH服务，这个用户是Gitea内部虚拟的；如果是系统sshd的git用户，也是被限制了shell权限的普通用户），只能执行Git相关的操作，不能随便修改服务器文件或进行管理操作。
• 验证机制：
  • ssh root@xxx验证的是系统root用户家目录下~/.ssh/authorized_keys里的公钥，或者系统的密码体系。
  • ssh git@xxx如果是连接Gitea服务，验证的是Gitea数据库里存储的用户公钥；如果是连接系统sshd，验证的是系统git用户的~/.ssh/authorized_keys。
• 用途：
  • ssh root@xxx是用于服务器运维管理的命令。
  • ssh git@xxx是用于和代码托管服务（Gitea/GitLab）交互、推送/拉取代码的专用命令。

内容的提问来源于stack exchange，提问作者ebyte