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
Also, GitExtensions is able to connect to Gitea with the following SSH URL:
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.
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
PS C:\Users\alexa\.ssh> ssh -v firstname.lastname@example.org -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@example.com debug1: kex: host key algorithm: ssh-rsa debug1: kex: server->client cipher: aes128-ctr MAC: firstname.lastname@example.org compression: none debug1: kex: client->server cipher: aes128-ctr MAC: email@example.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
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 firstname.lastname@example.org -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.