My computer: Windows 10 Pro 1909

I have a Gitea server running in my office, at local IP address, 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

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.enter image description here

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 [] 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 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 '[]: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 ([]: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.

2 Answers 2


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.


  • 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 [] 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.

  • I get the same result using GIT CMD. I've updated to the last git version for Windows (git version 2.25.0.windows.1) but I don't see any difference. How is the git client itself related to this issue? I think I've eliminated effects of my local git client, because I'm just trying to form an SSH connection. I've tried using both Windows built-in SSH and the SSH package provided by GOW. The permissions of id_rsa and parent folders are as you suggested: they only have the permissions for SYSTEM, my user (which is actually my email, not alexa), and Administrators.
    – afarley
    Feb 11, 2020 at 22:54

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/

  • I think you may have mis-read my question, I'm saying that I don't get that message, which is the expected result of logging in via SSH (not an error message)
    – afarley
    Feb 17, 2020 at 5:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.