Why can't I connect to Gitea using ssh via command line?

Question

My computer: Windows 10 Pro 1909

I have a Gitea server running in my office, at local IP address 10.100.10.24, with SSH configured on port 22000. Gitea is configured to use port 3000 for HTTP.

I'm able to access the Gitea website through my desktop, which is not the same PC that Gitea is running on, at URL http://10.100.10.24:3000/.

Also, GitExtensions is able to connect to Gitea with the following SSH URL:

ssh://[email protected]:22000/afarley/[XXXXXXXX].git

I started trying to set up TeamCity on my desktop to build this repository. However, when I configure this repo in TeamCity, I'm unable to connect. To drill down, I've tried to connect via ssh using the command-line.

However, it seems that I'm unable to log in to the Gitea server via SSH; I don't get the expected response:

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.

Rather, the entire terminal just seems to hang.

Things I have checked so far:

• The keyfile I'm pointing to (id_rsa) is PEM-formatted by exporting OpenSSH format from PuttyGen
• id_rsa has been set to 400 permissions via 'chmod 400 id_rsa' (does this make sense? I'm using Windows 10)

The issue feels similar to this: https://github.com/PowerShell/Win32-OpenSSH/issues/1334

But the discussion for that issue seems to go dead around Jul 9, 2019. I can't believe that the openssh client on Windows 10 is this broken; am I doing something else wrong?

---

Here's what I get if I add the -v flag:

PS C:\Users\alexa\.ssh> ssh -v [email protected] -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: [email protected]
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-ctr MAC: [email protected] compression: none
debug1: kex: client->server cipher: aes128-ctr MAC: [email protected] 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

---

Edit: About 2 weeks later, I was investigating/making some changes to the apache configuration for this server and SSL started working. I'm not sure what the original issue was, but the short story is that I was able to get a clean integration between a self-hosted Gitea/TeamCity and GitExtensions on my desktop.

There is no issue with the ssh command above (ssh -T -v [email protected] -p 22000); it gives the expected result now.

The issue may have been that the VM running Gitea had gone to sleep; our office machine apparently is pausing the Hyper-V VM when it goes to sleep.

Answer 1

OK, there seems to be two problems here.

---

SSH hanging after connection

It's probably a problem on the client tty due to limitations of MinGW. In the past I've encountered that ssh was unable to ioctl the local tty because the lack of a control device (pty). I've used https://github.com/rprichard/winpty at the time, but I think that newer versions of MinGW/MinGW64 (the Posix layer installed to run bash by Git) have that covered because I didn't see that problem anymore.

Summary:

• Try upgrading git in your Windows client to the latest version (best option).
• Try using GIT CMD instead of GIT BASH.
• If you're not using the GIT components on Windows, try invoking ssh from a Command window.

---

SSH not using your key

I suspect that this is your problem:

debug1: identity file C:\\Users\\alexa\\.ssh\\id_rsa type -1

In my PC, I get the following:

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

As to why you're getting type -1, it might be a permissions problem. Make sure that all C:\Users\alexa, C:\Users\alexa\.ssh and C:\Users\alexa\.ssh\id_rsa have only permissions for SYSTEM, alexa and Administrators.

Also, please notice that you're getting double backslashes in your log (e.g. C:\\Users\\alexa\\.ssh\\id_rsa instead of C:\Users\alexa\.ssh\id_rsa). I don't get double backslashes in mine.

Answer 2

Looks like you needs to install it another way. The errors message does give you a hint

and setup Gitea under another user

The docs say

Gitea should be run with a dedicated non-root system account on UNIX-type systems. Note: Gitea manages the ~/.ssh/authorized_keys file. Running Gitea as a regular user could break that user’s ability to log in.

Check here under the system requirements https://docs.gitea.io/en-us/