You have to upload your public key to Heroku:
heroku keys:add ~/.ssh/id_rsa.pub
If you don't have a public key, Heroku will prompt you to add one automatically which works seamlessly. Just use:
heroku keys:add
To clear all your previous keys do :
heroku keys:clear
To display all your existing keys do :
heroku keys
EDIT:
The above did not seem to work for me. I had messed around with the HOME environment variable and so SSH was searching for keys in the wrong directory.
To ensure that SSH checks for the key in the correct directory do :
ssh -vT git@heroku.com
Which will display the following ( Sample ) lines
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007
debug1: Connecting to heroku.com [50.19.85.156] port 22.
debug1: Connection established.
debug1: identity file /c/Wrong/Directory/.ssh/identity type -1
debug1: identity file /c/Wrong/Directory/.ssh/id_rsa type -1
debug1: identity file /c/Wrong/Directory/.ssh/id_dsa 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_4.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host 'heroku.com' is known and matches the RSA host key.
debug1: Found key in /c/Wrong/Directory/.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: 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: /c/Wrong/Directory/.ssh/identity
debug1: Trying private key: /c/Wrong/Directory/.ssh/id_rsa
debug1: Trying private key: /c/Wrong/Directory/.ssh/id_dsa
debug1: No more authentication methods to try.
Permission denied (publickey).
From the above you could observe that ssh looks for the keys in the /c/Wrong/Directory/.ssh directory which is not where we have the public keys that we just added to heroku ( using heroku keys:add ~/.ssh/id_rsa.pub ) ( Please note that in windows OS ~ refers to the HOME path which in win 7 / 8 is C:\Users\UserName )
To view your current home directory do : echo $HOME or echo %HOME% ( Windows )
To set your HOME directory correctly ( by correctly I mean the parent directory of .ssh directory, so that ssh could look for keys in the correct directory ) refer these links :
SO Answer on how to set Unix environment variable permanently
SO Question regarding ssh looking for keys in the wrong directory and a solution for the same.
Quick solution:
With this kind of error, I usually start by raising the postBuffer size by:
git config --global http.postBuffer 524288000
(some comments below report having to double the value):
git config --global http.postBuffer 1048576000
(For npm publish, Martin Braun reports in the comments setting it to no more than 50 000 000 instead of the default 1 000 000)
###More information:
From the git config man page, http.postBuffer is about:
Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally. Default is 1 MiB, which is sufficient for most requests.
Even for the clone, that can have an effect, and in this instance, the OP Joe reports:
[clone] works fine now
Note: if something went wrong on the server side, and if the server uses Git 2.5+ (Q2 2015), the error message might be more explicit.
See "Git cloning: remote end hung up unexpectedly, tried changing postBuffer but still failing".
Kulai (in the comments) points out to this Atlassian Troubleshooting Git page, which adds:
Error code 56 indicates a curl receive the error of CURLE_RECV_ERROR which means there was some issue that prevented the data from being received during the cloning process.
Typically this is caused by a network setting, firewall, VPN client, or anti-virus that is terminating the connection before all data has been transferred.
It also mentions the following environment variable, order to help with the debugging process.
# Linux
export GIT_TRACE_PACKET=1
export GIT_TRACE=1
export GIT_CURL_VERBOSE=1
#Windows
set GIT_TRACE_PACKET=1
set GIT_TRACE=1
set GIT_CURL_VERBOSE=1
With Git 2.25.1 (Feb. 2020), you know more about this http.postBuffer "solution".
See commit 7a2dc95, commit 1b13e90 (22 Jan 2020) by brian m. carlson (bk2204).
(Merged by Junio C Hamano -- gitster -- in commit 53a8329, 30 Jan 2020)
(Git Mailing list discussion)
docs: mention when increasing http.postBuffer is valuable
Signed-off-by: brian m. carlson
Users in a wide variety of situations find themselves with HTTP push problems.
Oftentimes these issues are due to antivirus software, filtering proxies, or other man-in-the-middle situations; other times, they are due to simple unreliability of the network.
However, a common solution to HTTP push problems found online is to increase http.postBuffer.
This works for none of the aforementioned situations and is only useful in a small, highly restricted number of cases: essentially, when the connection does not properly support HTTP/1.1.
Document when raising this value is appropriate and what it actually does, and discourage people from using it as a general solution for push problems, since it is not effective there.
So the documentation for git config http.postBuffer now includes:
http.postBuffer
Maximum size in bytes of the buffer used by smart HTTP transports when POSTing data to the remote system.
For requests larger than this buffer size, HTTP/1.1 and Transfer-Encoding: chunked is used to avoid creating a massive pack file locally.
Default is 1 MiB, which issufficient for most requests.
Note that raising this limit is only effective for disabling chunked transfer encoding and therefore should be used only where the remote server or a proxy only supports HTTP/1.0 or is noncompliant with the HTTP standard.
Raising this is not, in general, an effective solution for most push problems, but can increase memory consumption significantly since the entire buffer is allocated even for small pushes.
Best Answer
The issue could be that Github isn't present in your ~/.ssh/known_hosts file.
Append GitHub to the list of authorized hosts:
ssh-keyscan -H github.com >> ~/.ssh/known_hosts