为什么我不能通过命令行使用ssh连接到Gitea？
我的电脑: Windows 10 Pro 1909
我有一个Gitea服务器在我的办公室运行，位于本地IP地址10.100.10.24，SSH配置在端口22000上。Gitea被配置为对HTTP使用端口3000。
我可以通过我的桌面访问Gitea网站，这不是Gitea正在运行的PC，在URL http://10.100.10.24:3000/.上
此外，GitExtensions还可以使用以下SSH连接到Gitea：
ssh://git@10.100.10.24:22000/afarley/[XXXXXXXX].git我开始尝试在我的桌面上设置TeamCity来构建这个存储库。但是，当我在TeamCity中配置这个回购时，我无法连接。为了深入研究，我尝试使用命令行通过ssh进行连接。
但是，我似乎无法通过SSH登录到Gitea服务器；我没有得到预期的响应：
Hi there, You've successfully authenticated, but Gitea does not provide shell access.
If this is unexpected, please log in with password and setup Gitea under another user.相反，整个航站楼似乎只是悬着。
到目前为止，我检查过的东西：
- 我所指向的密钥文件(id_rsa)是通过从PuttyGen导出OpenSSH格式来格式化的
- id_rsa已通过'chmod 400 id_rsa‘设置为400个权限(这有意义吗？)我正在使用Windows 10)
这个问题与此类似：https://github.com/PowerShell/Win32-OpenSSH/issues/1334
但是，关于这个问题的讨论似乎在2019年7月9日结束了。我不敢相信Windows 10上的openssh客户端是不是坏了，我是不是做错了什么？
如果我添加-v标志，下面是我得到的结果：
PS C:\Users\alexa\.ssh> ssh -v git@10.100.10.24 -p 22000 -i C:\Users\alexa\.ssh\id_rsa
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Connecting to 10.100.10.24 [10.100.10.24] port 22000.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\alexa\\.ssh\\id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file C:\\Users\\alexa\\.ssh\\id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_7.7
debug1: Remote protocol version 2.0, remote software version Go
debug1: no match: Go
debug1: Authenticating to 10.100.10.24:22000 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa SHA256:KuxUCu3Lh34jm8eqvengtJ10f+TG/mgPSRzrT+oBxGg
debug1: Host '[10.100.10.24]:22000' is known and matches the RSA host key.
debug1: Found key in C:\\Users\\alexa/.ssh/known_hosts:1
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: pubkey_prepare: ssh_get_authentication_socket: No such file or directory
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: C:\\Users\\alexa\\.ssh\\id_rsa
debug1: Authentication succeeded (publickey).
Authenticated to 10.100.10.24 ([10.100.10.24]:22000).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: console supports the ansi parsing编辑:大约两周后，我正在调查/修改这个服务器的apache配置，SSL开始工作。我不知道最初的问题是什么，但短故事是，我能够在我的桌面上获得一个自我托管的Gitea/TeamCity和GitExtensions之间的清晰集成。
上面的ssh命令(ssh -T -v git@10.100.10.24 -p 22000)没有问题；它现在给出了预期的结果。
问题可能是运行着Gitea的VM已经睡了；我们的办公机器显然是暂停了超级VM的睡眠。
回答 2
DevOps用户
发布于 2020-02-11 22:38:45
好的，这里似乎有两个问题。
连接后的
SSH挂起
由于MinGW的限制，这可能是客户端tty上的一个问题。在过去，我曾遇到过ssh由于缺少控制设备(pty)而无法ioctl本地tty。我当时使用过https://github.com/rprichard/winpty，但我认为新版本的MinGW/MinGW 64(为运行Git运行bash而安装的Posix层)已经覆盖了，因为我再也没有看到这个问题了。
摘要：
- 尝试将Windows客户端中的git升级到最新版本(最佳选项)。
- 尝试使用
GIT CMD而不是GIT BASH。 - 如果没有在Windows上使用GIT组件，请尝试从命令窗口调用
ssh。
SSH不使用您的密钥
我怀疑这是你的问题：
debug1: identity file C:\\Users\\alexa\\.ssh\\id_rsa type -1在我的电脑里，我得到了以下信息：
debug1: Reading configuration data /c/Users/xxxx/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to xxx [192.168.0.1] port 22.
debug1: Connection established.
debug1: identity file /c/Users/xxxx/.ssh/id_rsa type 0至于为什么要输入-1，可能是权限问题。确保所有C:\Users\alexa、C:\Users\alexa\.ssh和C:\Users\alexa\.ssh\id_rsa只对SYSTEM、alexa和Administrators具有权限。
另外，请注意日志中有双反斜杠(例如，C:\\Users\\alexa\\.ssh\\id_rsa而不是C:\Users\alexa\.ssh\id_rsa)。我的车里没有双反斜杠。
DevOps用户
发布于 2020-02-16 14:12:26
看来你需要另一种方式来安装它。错误信息确实给了您一个提示。
并在另一个用户下设置Gitea。
医生说
Gitea应该在UNIX类型系统上使用一个专用的非根系统帐户来运行。注意: Gitea管理~/..ssh/authorized_keys文件。将Gitea作为常规用户运行可能会破坏该用户的登录能力。
在系统需求https://docs.gitea.io/en-us/下检查这里
https://devops.stackexchange.com/questions/10772
复制相似问题
腾讯云开发者
