Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to log into Ubuntu desktop. I get the following error message:

PTY allocation request failed

What does it mean and how to connect to my desktop?

This is the output with -v:

debug1: Reading configuration data /home/evag/.ssh/config  
debug1: /home/evag/.ssh/config line 1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config 
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: auto-mux: Trying existing master
debug1: mux_client_request_session: master session id: 2
PTY allocation request failed

Given the output presented above with the verbose option, I think I understand where the problem comes from: I have two computers, A and B. I'm using a controlmaster in A to keep persistent connections to B. A logs into B in a safe way, with command=/bin/false to limit the usage A has on B (it has only forwarding capabilities).

However I would want to connect to ssh from A to B without using this identity (-i), but the problem is that since there is a persistent connection, it uses the existing connection regardless of the option I put in -i, so I end up with not being able to allocate a PTY.

So given that there is an existing controlmaster and protected connection from A to B, how can I get another connection from A to B, but this time with full rights?

share|improve this question
Stupid idea: What about setting up 2 SSH server instances independent of each other on different ports? – hexafraction Jul 9 '12 at 11:51
No idea is stupid, thanks for the effort. It's probably not optimal but it's a nice workaround. However I don't know how to do that either, if you have a step by step guide that would be very helpful. – evaG Jul 9 '12 at 12:18
I'll look for a guide when I have time. – hexafraction Jul 9 '12 at 12:20

I'm assuming that you have specified the ControlPath and ControlMaster in ~/.ssh/config ? In which case ssh will always check for the ControlPath when attempting to access that server. As I understand it this is the default if a ControlPath exists even if ControlMaster=no is set (because it is automatically set to 'no' if the ControlPath exists so as not to attempt to create a new ControlMaster).

You will need to specify a new ControlPath:

ssh -o ControlPath=~/.ssh/%r@%h:%p-newsession server

However: I do the same thing but do not need to tell it to run 'false', I simply use the available options in SSH. See the man page for a way to create forwarding connections without starting a shell. When done properly the PTY is only allocated as needed, even over the same control connection.

-f      Requests ssh to go to background just before command execution.
-N      Do not execute a remote command.  This is useful for just forwarding ports.
-T      Disable pseudo-tty allocation.

So in my case (along with other, unrelated options):

ssh -fNT server

where ~/.ssh/config already specifies the ControlPath.

share|improve this answer

Your Answer


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.