Answers: <p>OK, there seems to be two problems here.</p>
  
  <hr>
  
  <h3>SSH hanging after connection</h3>
  
  <p>It's probably a problem on the client tty due to limitations of MinGW. In the past I've encountered that <code>ssh</code> was unable to <code>ioctl</code> the local <code>tty</code> because the lack of a control device (<code>pty</code>). I've used <a href="https://github.com/rprichard/winpty" rel="nofollow noreferrer">https://github.com/rprichard/winpty</a> 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.</p>
  
  <p>Summary:</p>
  
  <ul>
  <li>Try upgrading git in your Windows client to the latest version (best option).</li>
  <li>Try using <code>GIT CMD</code> instead of <code>GIT BASH</code>.</li>
  <li>If you're not using the GIT components on Windows, try invoking <code>ssh</code> from a Command window.</li>
  </ul>
  
  <hr>
  
  <h3>SSH not using your key</h3>
  
  <p>I suspect that this is your problem:</p>
  
  <pre><code>
  debug1: identity file C:\\Users\\alexa\\.ssh\\id_rsa type -1
  </code></pre>
  
  <p>In my PC, I get the following:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>As to why you're getting type <code>-1</code>, it <em>might</em> be a permissions problem. Make sure that all <code>C:\Users\alexa</code>, <code>C:\Users\alexa\.ssh</code> <em>and</em> <code>C:\Users\alexa\.ssh\id_rsa</code> have only permissions for <code>SYSTEM</code>, <code>alexa</code> and <code>Administrators</code>.</p>
  
  <p>Also, please notice that you're getting double backslashes in your log (e.g. <code>C:\\Users\\alexa\\.ssh\\id_rsa</code> instead of <code>C:\Users\alexa\.ssh\id_rsa</code>). I don't get double backslashes in mine.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-02-11T22:54:44.790Z
Answers: 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.
Answers: afarley
Answers: CC BY-SA 4.0
Answers: 2020-02-11T22:38:45.850Z
Answers: 2020-02-11T22:38:45.850Z
Answers: Guillermo Prandi
Answers: <p>Looks like you needs to install it another way. The errors message does give you a hint </p>
  
  <blockquote>
    <p>and setup Gitea under another user</p>
  </blockquote>
  
  <p>The docs say </p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>Check here under the system requirements <a href="https://docs.gitea.io/en-us/" rel="nofollow noreferrer">https://docs.gitea.io/en-us/</a></p>
  
Answers: CC BY-SA 4.0
Answers: 2020-02-17T05:25:31.327Z
Answers: 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)
Answers: afarley
Answers: CC BY-SA 4.0
Answers: 2020-02-16T14:12:26.000Z
Answers: 2020-02-16T14:12:26.000Z
Answers: MonkeyMagic
Body: <p>My computer: Windows 10 Pro 1909</p>
  
  <p>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.</p>
  
  <p>I'm able to access the Gitea website through my desktop, which is not the same PC that Gitea is running on, at URL <code>http://10.100.10.24:3000/.</code></p>
  
  <p>Also, GitExtensions is able to connect to Gitea with the following SSH URL:</p>
  
  <pre><code>ssh://git@10.100.10.24:22000/afarley/[XXXXXXXX].git
  </code></pre>
  
  <p>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.</p>
  
  <p>However, it seems that I'm unable to log in to the Gitea server via SSH; I <strong>don't</strong> get the expected response:</p>
  
  <pre><code>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.
  </code></pre>
  
  <p>Rather, the entire terminal just seems to hang.<a href="https://i.sstatic.net/f8UxS.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/f8UxS.png" alt="enter image description here"></a></p>
  
  <p>Things I have checked so far:  </p>
  
  <ul>
  <li>The keyfile I'm pointing to (id_rsa) is PEM-formatted by exporting OpenSSH format from PuttyGen  </li>
  <li>id_rsa has been set to 400 permissions via 'chmod 400 id_rsa' (does this make sense? I'm using Windows 10)  </li>
  </ul>
  
  <p>The issue feels similar to this:
  <a href="https://github.com/PowerShell/Win32-OpenSSH/issues/1334" rel="nofollow noreferrer">https://github.com/PowerShell/Win32-OpenSSH/issues/1334</a></p>
  
  <p>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?</p>
  
  <hr>
  
  <p>Here's what I get if I add the <code>-v</code> flag:</p>
  
  <pre><code>PS C:\Users\alexa\.ssh&gt; 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-&gt;client cipher: aes128-ctr MAC: hmac-sha2-256-etm@openssh.com compression: none
  debug1: kex: client-&gt;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
  </code></pre>
  
  <hr>
  
  <p>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. </p>
  
  <p>There is no issue with the ssh command above (<code>ssh -T -v git@10.100.10.24 -p 22000</code>); it gives the expected result now.</p>
  
  <p>The issue <em>may</em> 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.</p>
  
Tags: <git><ssh>
Title: Why can't I connect to Gitea using ssh via command line?
UserDisplayName: afarley
ThreadText: # Why can't I connect to Gitea using ssh via command line?
  
  (Asked by: username_0 on 2020-02-11)
  
  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://git@10.100.10.24:22000/username_0/[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](https://i.sstatic.net/f8UxS.png)](https://i.sstatic.net/f8UxS.png)
  
  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 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
  
  ```
  
  ---
  
  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 git@10.100.10.24 -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.
  
  **Tags:** git, ssh
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2020-02-11. Score: 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.
  
  > **Comments:**
  > **username_0**: 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.  
  
  ---
  
  ### Answer by username_2 on 2020-02-16. Score: 0
  
  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/>
  
  > **Comments:**
  > **username_0**: 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)  
  
  ---
  
  