Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I just generated a public and private key with ssh key gen. I uploaded the public key onto a gitlab (basically a clone of git hub) system for my university and got an email saying that I successfully uploaded the key. When I try to run a git clone command, I get

Cloning into 'csci6990-hci-f13'...
ssh_exchange_identification: Connection closed by remote host
fatal: The remote end hung up unexpectedly

I am trying to understand if I did everything properly before blaming the git lab system. With that said, when I uploaded a public key onto git lab there were no instructions/steps for telling gitlab where the private key resides in on my mac os x. This makes me think that maybe sshkeygen automatically puts the key into some kind of standard repository location? Is that the case? If not, then how can I upload a public key and have it work without telling the remote system where the corresponging private key sits within the file system?

Edit: this is the output of ssh -vvv

OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to gitlab.cs.uno.edu [137.30.120.92] port 22.
debug1: Connection established.
debug1: identity file /Users/abramhandler/.ssh/id_rsa type -1
debug1: identity file /Users/abramhandler/.ssh/id_rsa-cert type -1
debug1: identity file /Users/abramhandler/.ssh/id_dsa type -1
debug1: identity file /Users/abramhandler/.ssh/id_dsa-cert type -1
ssh_exchange_identification: Connection closed by remote host
share|improve this question
1  
I would connect to the host with ssh -vvv so you get some more ideas as to what the error is. –  Drav Sloan Sep 17 '13 at 18:55
    
@DravSloan thanks. see my edit –  akh2103 Sep 17 '13 at 18:58
    
Which is informing your rsa keys are not being accepted for that user account you are trying to access. You may have to set the user you are connecting with? –  Drav Sloan Sep 17 '13 at 19:05
    
And also, by default sshd looks in ~user/.ssh/authorized_keys file (where ~user is the home directory of the user you are attempting to connect as). It can be overwrote by the AuthorizedKeysFile option inside your ssh configuration file. –  Drav Sloan Sep 17 '13 at 19:12
1  
Sorry, @DravSloan, I think you're wrong - the problem is not that the server isn't just accepting his key. Here's an example output of how that would actually look. Instead the server closes the connection even before it identified itself as a SSH server, so I'd say that whatever is running on port 22, it's not a working SSH server. –  Martin von Wittich Sep 17 '13 at 20:54
show 2 more comments

3 Answers 3

there were no instructions/steps for telling gitlab where the private key resides in on my mac os x

The remote server does not need to know where your local private key is. It never sees it and never should. It stays on your machine and is not transmitted, ever.

This makes me think that maybe sshkeygen automatically puts the key into some kind of standard repository location?

There's a default filename mentioned when it asks you to (optionally) set your own key name, probably /home/you/.ssh/id_rsa. That's the private key. It also creates a public key with the .pub suffix. If you name them yourself, you may put them anywhere, but AFAIK both files must be in the same directory.

If you don't use the default name, in order to use the key, you either have to register it with ssh-agent via ssh-add, or else specify it on the command line when you invoke ssh, e.g.:

ssh -i ~/.ssh/mykey ....

Notice that's not mykey.pub, but (as mentioned) mykey.pub should be in the same directory as mykey. I.e., -i refers to the private key. If the key is password protected, you'll be asked for that. Then ssh sends the public key to the server.

If you don't specify a key with -i, the /home/you/.ssh/id_rsa key, if any, will be used. If you are using the default key, you can ignore the rest of this.


To use a non-default key with git (i.e., if you opted out of "id_rsa"), you will have to register it first with ssh-agent. The idea behind ssh-agent is you use it to invoke a shell or some other persistent application which will parent a shell from which you invoke git (such as the GUI itself, probably there is an OSX specific method). For example:

> ssh-agent bash

Starts a new bash subshell under ssh-agent. Next:

> ssh-add ~/.ssh/mykey

Again, the private key. You can add as many of these as you like. Subsequently when ssh is used within that shell or a child thereof, it will try that list of keys automatically with the remote server. To clone with git:

git clone ssh://me@wherever/some/repo/path 
share|improve this answer
add comment

Yes. Your private key should be in ~/.ssh/id_rsa or ~/.ssh/id_dsa depending on what kind of key you generated. Ensure the permissions are strict on the file.

You may also want to set up an agent to cache the passphrase you used with the key to further simplify the configuration.

share|improve this answer
add comment

Is it possible that you are behind a router that somehow filters or mangles your outgoing connections to the SSH port of 137.30.120.92? Because I can connect to that server just fine:

martin@martin ~ % ssh 137.30.120.92
The authenticity of host '137.30.120.92 (137.30.120.92)' can't be established.
ECDSA key fingerprint is 45:45:c0:59:c6:c9:50:22:7d:45:bf:cc:e2:9a:99:31.
+--[ECDSA  256]---+
|        .o=@*+o  |
|         o+o=  . |
|          ..    .|
|         .    o .|
|        S    . + |
|            . .  |
|           E .   |
|            B    |
|           =     |
+-----------------+
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '137.30.120.92' (ECDSA) to the list of known hosts.
Ubuntu 12.04.2 LTS gitlab ssh-pty

Password: 

Your output Connection closed by remote host however suggests that your ssh client is never really able to talk to the SSH server - the server does accept the connection, but it doesn't reply to your ssh client.

Also on a related note - Connection closed by remote host may be a symptom of a server that has crashed, at least that's the usual situation where I encounter this error. That shouldn't be the case here though because then I'd get the same error.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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