When you run
ssh firstname.lastname@example.org in a normal terminal environment, your SSH client (the ssh process on your local machine) will request a psuedo-terminal (pty) from the server.
GitHub has always denied pty allocation.
Older versions (prior to 5.6) of OpenSSH’s ssh will “fall back” to no-pty mode if the server rejected its pty allocation request.
Newer versions (5.6 through 5.8) of OpenSSH’s ssh abort if the server rejects its pty allocation request.
The latest versions (5.9 and later) of OpenSSH’s ssh will take the former action (continue) if the pty allocation was done automatically, and the latter action (abort) if there was an explicit request for a pty (
-t given or
RequestTTY equal to
You can tell ssh (either old or new) to avoid requesting a pty allocation by using the
ssh -T email@example.com
You should then see the GitHub message:
Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.
From the OpenSSH 5.6 release announcement:
- Kill channel when pty allocation requests fail. Fixed stuck client
if the server refuses pty allocation (bz#1698)
bz#1698 seems to be a reference to a report logged in the “Portable OpenSSH” Bugzilla.
From the check-in message of OpenSSH clientloop.c rev 1.234:
improve our behaviour when TTY allocation fails: if we are in
RequestTTY=auto mode (the default), then do not treat at TTY
allocation error as fatal but rather just restore the local TTY
to cooked mode and continue. This is more graceful on devices that
never allocate TTYs.
If RequestTTY is set to "yes" or "force", then failure to allocate
a TTY is fatal.