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

Question

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

Answer 1

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.

Answer 2

Try adding
ClientAliveInterval 15
Original answer:
Try adding the following line to your /etc/ssh/ssh_config
ServerAliveInterval 120