Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

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

2 Answers 2

Please post the results from: ssh -v youruser@yourserver.

You'll probably need to:

sudo rm -rf /root/.ssh/authorized_keys
sudo service ssh restart

If that doesnt work:

sudo rm -rf ~/.ssh/authorized_keys
sudo service ssh restart
share|improve this answer
see edit................. –  evaG Jul 9 '12 at 9:19
Have you tried what i said above? –  LnxSlck Jul 9 '12 at 10:00
As far as using -v, yes. But I do not want to remove my authorized_keys, sorry. I'll edit once more to give details as to what might be the problem in my opinion –  evaG Jul 9 '12 at 11:13
This is a pretty dump suggestion. Why would you suggest to remove the authorized_keys file, potentially locking out noobish users who follow your advice. –  Overbryd Mar 17 '14 at 15:51

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.