Stuck with Gitolite on OSX - macos

I am in the process of installing the latest version of gitolite on an osx mountain lion server. I set it up under it's own 'git' user account and followed the instructions here: https://github.com/sitaramc/gitolite
I am getting stuck in trying to check-out the gitolite-admin repo from the server on my workstation. I run this command:
git clone git#gitserver:gitolite-admin
but get this in return:
Cloning into 'gitolite-admin'...
Connection closed by gitserver
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
It seems that I got the SSH set-up correctly because it's not asking for a PWD but I am stuck on where to look to try to debug the problem.
Thanks,
Grant
result from ssh -v
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to gitserver [gitserver] port 22.
debug1: Connection established.
debug1: identity file /Users/xxx/.ssh/id_rsa type 1
debug1: identity file /Users/xxx/.ssh/id_rsa-cert type -1
debug1: identity file /Users/xxx/.ssh/id_dsa type -1
debug1: identity file /Users/xxx/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9
debug1: match: OpenSSH_5.9 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA xxxxx
debug1: Host 'gitserver' is known and matches the RSA host key.
debug1: Found key in /Users/xxx/.ssh/known_hosts:5
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/xxx/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: read PEM private key done: type RSA
Connection closed by gitserver
Looks OK here unless I am missing some detail.

I had a similar issue configuring a bare git repo in mountain lion. I uncommented the following lines of /etc/sshd_config:
PubkeyAuthentication yes
PermitUserEnvironment yes
The last one was related to the missing PATH error in .ssh/environment, but the first one was the one that allowed connections from ie. msysgit.
PS (edit): In the case of msysgit, I also setup the SSH agent (eval $(ssh-agent) && ssh-add) with OpenSSH key imported in pageant (as my GIT_SSH=path_to_plink). That did the trick.

On osx server, at least since 2015, also enable ssh access explicitly for the repository owner. In my case I have my server configured to allow only a few users. This caused very similar problems like you had.

Related

Git on Windows not asking for SSH key password, or using SSH Key

The fundamental problem is that I am never seeing a prompt to enter in my SSH-Key password, SSH-Agent or no. As such, it's acting like I entered the wrong password and defaulting to pretending I have no keys.
This is happening on multiple computers. I set up my ssh keys awhile ago, and everything is great, but every so often I will do a git push (usually after restarting my computer) and I will get asked for my git origin server's password RATHER than my ssh key's password. Since my origin server does not HAVE a password, this leaves me unable to push changes.
Sometimes it resolves itself after restarting, sometimes not. Usually I do a lot of flailing guesses and one of them ends up fixing the problem, but I can't currently remember which ones work and which don't.
What is the CORRECT way to go about fixing this? What is the actual problem? Is my SSH Key locked? Is some windows process not starting correctly? Is a Path variable being eaten? I don't know a lot about windows (usually I develop on linux), so I'm extra at a loss here.
Edit: The first answer mentions ssh-agent. Some googling got me to here:
https://help.github.com/articles/working-with-ssh-key-passphrases/#platform-windows
Which explains how to set up ssh-agent to autostart and know about your keys in windows. (I didn't even know you could use bash profiles in windows).
This did not help.
My git bash now says "Identity added: /c/Users/{{ME}}/.ssh/id_rsa" It does NOT ask me for my key password, and I still cannot push to my origin server (it asks for a server password, still).
I can confirm that my ssh key does live in the place the agent is looking. I can also confirm that the key is added: ssh-add -l shows a single key, from the location my key is stored.
Edit: Setting GIT_SSH as an environment variable pointing at the executable for ssh does nothing either, but it was a long shot anyways.
Edit: ssh git#git.myhost.com outputs:
$ ssh -v git#git.myhost.lan
OpenSSH_6.6.1, OpenSSL 1.0.1i 6 Aug 2014
debug1: Reading configuration data /c/Users/eschjen/.ssh/config
debug1: /c/Users/eschjen/.ssh/config line 1: Applying options for git.myhost
.lan
debug1: Connecting to git.myhost.lan [10.116.22.40] port 22.
debug1: Connection established.
debug1: identity file /c/Users/eschjen/.ssh/id_rsa type 1
debug1: identity file /c/Users/eschjen/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA ae:81:77:0d:1c:8e:6a:aa:a8:69:36:1b:e4:ca:33:ee
debug1: Host 'git.myhost.lan' is known and matches the RSA host key.
debug1: Found key in /c/Users/eschjen/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
c,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/eschjen/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mi
c,password
debug1: Next authentication method: password
git#git.myhost.lan's password:
The output screen helped me take the tack that the ssh key was being used, but rejected by the server. I found that the ssh key my server knows about does not match the ssh key my machine has, somehow, despite everything working fine less than a month ago. I re-added the ssh key I have, and was able to push my changes.
Anybody have any idea how the ssh key would be re-generated (I'm fairly sure I didn't do it explicitly) during all of this?
It's not enough to add the identity. There should be a file called config(no extension) in your C:\Users\{{username}}\.ssh directory.
You can define the key to use for a given host there like this:
Host myhost.name.com
IdentityFile ~/.ssh/my_keyfile_name
The result of correct configuration is a input request for a password:
Enter passphrase for key '/c/Users/{{username}}/.ssh/my_keyfile_name':
Edit1: You can retrieve the verbose output of ssh by adding the -v parameter. Real world example (host name replaced):
λ ssh -v igor#myhost.at
OpenSSH_6.6.1, OpenSSL 1.0.1m 19 Mar 2015
debug1: Reading configuration data /c/Users/Igor/.ssh/config
debug1: /c/Users/Igor/.ssh/config line 4: Applying options for myhost.at
debug1: Connecting to myhost.at [192.168.2.1] port 22.
debug1: Connection established.
debug1: identity file /c/Users/Igor/.ssh/myhost-server type -1
debug1: identity file /c/Users/Igor/.ssh/myhost-server-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 Debian-6+squeeze5
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze5 pat OpenSSH_5* compat 0x0c000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 67:3f:96:7b:6a:68:55:89:a8:30:a9:ed:67:ef:40:a4
debug1: Host 'myhost.at' is known and matches the RSA host key.
debug1: Found key in /c/Users/Igor/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /c/Users/Igor/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /c/Users/Igor/.ssh/myhost-server
debug1: key_parse_private2: missing begin marker
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/c/Users/Igor/.ssh/myhost-server':
I think this would help tremendously. Added comment to OP requesting this information.
you need to tell your computer to add the key again after restarting the system. Most of the time this is done with the ssh-agent
I wasted several hours trying to solve the same problem - SSH would not ask for the passphrase for my keypair even with pageant NOT running.
SSH uses different key formats (SSH-1 and SSH-2), and more importantly, refuses to read RSA keys if they are in SSH-2 format. Generating the keypair with Puttygen and then converting it to SSH-1 format to save in .ssh\id_rsa solved the problem for me.
Generate a keypair
Save it with a meaningful name (like Basement-Computer.ppk)
Export the file to OpenSSH format and save it with the name id_rsa (no extension)
Git clone will now ask for the passphrase (or at least it did for me). Google's instructions for setting up a Git repo https://cloud.google.com/source-repositories/docs/authentication#ssh neglects to mention that crucial third step.

Permission Denied Error when using scp to copy a file to Amazon EC2 instance from Mac OS

I have read several StackOverflow articles on this problem and googled other sources with no luck. I've checked AWS documentation and can't resolve the issue. I have been working on this for several hours and am really stuck.
I've found articles referring to similar problems but the issue looks to always be a typo or mistake on the user's part. In my case, I'm confident I have ensured there are no typos or errors in what I'm doing.
I'm using Mac OS X Yosemite to connect to my AWS EC2 instance. I cannot scp files from my local machine to my instance, but I have been able to in the past, I believe before I upgraded to Yosemite (although I'm not 100% certain about before or after the upgrade). Regardless, I'm now getting a permission denied error.
I am able to ssh just fine into my instance. I do so like this:
ssh -i mykey.pem ec2-user#myEC2host.myzone.compute.amazonaws.com
Everything works fine with the ssh. But when I attempt scp like this:
scp —i mykey.pem ~/Sites/test.html ec2-user#myEC2host.myzone.compute.amazonaws.com:/var/www/html/
I get the following error:
Permission denied (publickey). lost connection
I've been trying this for hours and have confirmed the following:
I CAN ssh in just fine.
My .pem file has 400 permissions and
is not viewable to the world.
I have correct permissions and ownership in the /var/www and /var/www/html folders
(I went through the amazon setup tutorial again and ensured I used all permission settings as they described. My user is part of the group with access to those folders.
When I run the scp -v command I can see that scp does not appear to be even trying to use the specified Identity file. I get the following output:
(Notice the program being executed has dropped the -i from the scp command)
Executing: program /usr/bin/ssh host myEC2host.myzone.compute.amazonaws.com, user ec2-user, command scp -v -d -t /var/www/html/
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to myEC2host.myzone.compute.amazonaws.com [public AWS ip] port 22.
debug1: Connection established.
debug1: identity file /Users/myusername/.ssh/id_rsa type -1
debug1: identity file /Users/myusername/.ssh/id_rsa-cert type -1
debug1: identity file /Users/myusername/.ssh/id_dsa type -1
debug1: identity file /Users/myusername/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA {some hex output}
debug1: Host 'myEC2host.myzone.compute.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /Users/myusername/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/myusername/.ssh/id_rsa
debug1: Trying private key: /Users/myusername/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
lost connection
However, when I run ssh -v I get the following output which DOES immediately use the correct Identify file:
ssh -v -i mykey ec2-user#myEC2host.myzone.compute.amazonaws.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to myEC2host.myzone.compute.amazonaws.com [54.69.211.59] port 22.
debug1: Connection established.
debug1: identity file mykey.pem type -1
debug1: identity file mykey.pem-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2
debug1: match: OpenSSH_6.2 pat OpenSSH*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm#openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm#openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA {some hex output}
debug1: Host 'myEC2host.myzone.compute.amazonaws.com' is known and matches the RSA host key.
debug1: Found key in /Users/myusername/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: mike.pem
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to myEC2host.myzone.compute.amazonaws.com ([myEC2IP]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_CA.UTF-8
I'm not sure what else to try or how I might be able to resolve this. I'm hoping somebody will have the same environment and can confirm the issue or supply a resolution.
Thanks in advance!
scp —i mykey.pem ~/Sites/test.html ec2-user#myEC2host.myzone.compute.amazonaws.com:/var/www/html/
Executing: program /usr/bin/ssh host myEC2host.myzone.compute.amazonaws.com, user ec2-user, command scp -v -d -t /var/www/html/
The dash in your scp —i... command is a unicode EM dash, not an ASCII dash. Scp isn't interpreting it as a command-line option.
In fact it interpreted "—i", "mykey.pem", and "~/Sites/test.html" as three files to be copied. You can tell this because scp added "-d" to the command line for the remote scp instance. The "-d" flag tells the remote scp instance that the target has to be a directory. scp adds that flag to the remote command when it's copying more than one file, but not for copying a single file.
Maybe you copied the scp command from a word processing document? Microsoft Word is notorious for changing dashes and quote marks to typesetting versions. It's something to be careful about.
Kenster correctly pointed out that the dash in the -i in my code was in fact converted to an EMdash prior to my pasting it into Terminal. :-s
Retyping the entire command corrected the issue.
Thanks for catching my oversight.

SSH Fingerprint not authorized on Heroku after git restore

I had to restore my master branch from github a couple weeks ago and since then I've been receiving an error that states "Your key with fingerprint... is not authorized to access my app."
I've looked at the previous answers to this problem and have tried deleting the old keypair, creating a new one and uploading it.
I used the following posts and still get the same error:
Your key with fingerprint .... is not authorized to access... myapp. The remote end hung up unexpectedly. HEROKU, GIT CLONE
Why is my key w/ fingerprint not authorized when I try to push latest changes to Heroku?
Cannot push to Heroku because key fingerprint
When I run ssh -Tv git#heroku.com the terminal outputs the following:
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/username/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: Connecting to heroku.com [50.19.85.154] port 22.
debug1: Connection established.
debug1: identity file /Users/anthonyfrancavilla/.ssh/id_rsa type 1
debug1: identity file /Users/anthonyfrancavilla/.ssh/id_rsa-cert type -1
debug1: identity file /Users/anthonyfrancavilla/.ssh/id_dsa type -1
debug1: identity file /Users/anthonyfrancavilla/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version Twisted
debug1: no match: Twisted
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA [rsa key redacted]
debug1: Host 'heroku.com' is known and matches the RSA host key.
debug1: Found key in /Users/anthonyfrancavilla/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/anthonyfrancavilla/.ssh/id_rsa_heroku
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to heroku.com ([50.19.85.154]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
shell request failed on channel 0
I discovered that the problem was in .git/config
The url under [remote "heroku"] was incorrect. I was able to reconnect once I corrected it.

ssh connection using cygwin

I am trying to connect with my remote linux server using cygwin+ssh but the authentication fails with no apparent reason. I have successfully setup another connnection to github successfully and I have followed the same process, this is why I am stopped here
$ ssh -v finxxx#xxx.79.xxx.29
OpenSSH_6.0p1, OpenSSL 1.0.1c 10 May 2012
debug1: Connecting to xxx.79.xxx.29 [xxx.79.xxx.29] port 22.
debug1: Connection established.
debug1: identity file /home/xxxtta/.ssh/id_rsa type -1
debug1: identity file /home/xxxtta/.ssh/id_rsa-cert type -1
debug1: identity file /home/xxxtta/.ssh/id_dsa type 2
debug1: identity file /home/xxxtta/.ssh/id_dsa-cert type -1
debug1: identity file /home/xxxtta/.ssh/id_ecdsa type -1
debug1: identity file /home/xxxtta/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA c7:b2:f1:f9:76:cd:24:5a:80:91:4b:e5:ac:7e:e1:ee
debug1: Host 'xxx.79.xxx.29' is known and matches the RSA host key.
debug1: Found key in /home/xxxtta/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/xxxtta/.ssh/id_rsa
debug1: Offering DSA public key: /home/xxxtta/.ssh/id_dsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/xxxtta/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
I have made the standard stuff but I cannot solve the problem. These are the commands I have used to generate the private/public keys. I have then copied the public key to the server
$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/xxxtta/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/xxxtta/.ssh/id_dsa.
Your public key has been saved in /home/xxxtta/.ssh/id_dsa.pub
thank you for your help
EDIT:
I have made the same procedure using MINGW and it works (I am able to connect). Something is definitely going wrong with cygwin in my system
Problem probably lies in user name. If you login remotely user name is case sensitive. You must write user name exactly how it was defined in Windows.
Copy id_dsa.pub to your remote server.
# scp .ssh/id_dsa.pub dude#remotemachine
On remote server:
# cat id_dsa.pub >> ~/.ssh/authorized_keys
You might try -vvv instead of -v to increase the verbosity.
Also, check that the file permissions are set properly. See Adding public key to ~/.ssh/authorized_keys does not log me in automatically

Error encountered when setup Github on Mac "Write failed: Broken pipe"

I have been facing this annoying error when trying to setup Github on Mac, OS version is Lion. Basically, I followed the steps as mentioned at this URL: http://help.github.com/mac-set-up-git/
I always stuck at the step of executing this command "ssh -T git#github.com"
I have tried to output the debugging message and below is the message log. The last message shows that it's due to an error 'Write failed: Broken pipe'.
Please give me a solution to fix this error if you have ever encountered this error before and able to fix it. Thanks a lot.
user-users-macbook:.ssh useruser$ ssh -vT git#github.com
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to github.com [207.97.227.239] port 22.
debug1: Connection established.
debug1: identity file /Users/useruser/.ssh/id_rsa type 1
debug1: identity file /Users/useruser/.ssh/id_rsa-cert type -1
debug1: identity file /Users/useruser/.ssh/id_dsa type -1
debug1: identity file /Users/useruser/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5github2
debug1: match: OpenSSH_5.1p1 Debian-5github2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /Users/useruser/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/useruser/.ssh/id_rsa
debug1: Remote: Forced command: gerve thsonvt
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Remote: Forced command: gerve thsonvt
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([207.97.227.239]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions#openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
Write failed: Broken pipe
Write failed: Broken pipe just means that, for whatever reason, the connection broken. This can happen for any number of reasons, such as a timeout occurring, or your connection to the server being broken due to your internet connection dropping out, etc. Increasing the ServerAliveInterval can help; ask at ServerFault if you're after more information about SSH settings, as it's off-topic for StackOverflow :)
For you, though, this is irrelevant; from your debug output it's pretty clear that you've set up your SSH keys successfully (debug1: Authentication succeeded (publickey) and following lines).
It also looks like you've done step 5 of that tutorial more than once; debug1: Found key in /Users/useruser/.ssh/known_hosts:1 means that you've already added the remote host to your list of known hosts (which is what typing yes is all about in step 5 of that tutorial).
Feel free to continue on to the next section (Then: Set Up Your Info); you've done everything you need to for step 1 to step 5.
Try adding
ClientAliveInterval 15
Original answer:
Try adding the following line to your /etc/ssh/ssh_config
ServerAliveInterval 120

Resources