Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Today, I've started to setup a gitolite server on my ubuntu 10.04 server, and I needed to generate a public/private key pair with ssh-keygen.

So far no problem. I've generated the 2 files (id_rsa & id_rsa.pub ) without any trouble on my Ubuntu 10.10 client, then transfered (copied) the id_rsa.pub key to the server ( in /tmp/ ) for installing the gitolite server.

But next, when I wanted to get connected by SSH to the server from the client, I was receiving an error that was looking something like:

PTY allocation request failed on channel 0 

Searching google, the answer I found were related to /etc/fstab. That kind of makes no sense in my case. I've then got the idea to remove the ~/.ssh/id_rsa and id_rsa.pub key from my client, and I was again able to establish a SSH connection.

Ca someone explain why that happenned ? I feel like I don't understand something about authentication keys.

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted

Gitolite sets up the authorized_keys file in such a way where you wouldn't have shell access to the server. There's a few ways around this:

  1. You can setup a password to log into the machine, and not use your SSH key except when you are using git.
  2. You can generate another SSH key to use to administrate the machine, this would require you use ssh -i to override the default key that is provided when logging in. If you choose this route, add your key manually (don't use gitolite), and make sure your key appears before any added by gitolite.

Basically, what happened is by design. Gitolite does not allow any user to get shell access to the server, so the (somewhat confusing) error message just indicates it's working properly.

share|improve this answer
add comment

One possible reason for that message is that the server has maxed out the number of available terminals, because too many users are connected at once. This would be a transient failure, as users connecting and disconnecting would saturate and desaturate the number of ptys.

Another possible reason, probably the one that applies to you, is that keys can be restricted to forbid terminal allocation. This isn't terribly useful in most cases, but makes sense for a server that's only allowing storage and not general use — for example git storage. If the key has the no-pty flag (check the corresponding line in ~/.ssh/authorized_keys), you won't be able to log in with a terminal.

If you're an administrator on a git server, you'll probably want to have a key without restrictions. Just run ssh-keygen without -O and ssh-copy-id to install a key without restrictions. Use restricted keys for ordinary users who run nothing but git on the server.

share|improve this answer
add comment

That error does not look like a key problem, something else is likely broken with your ssh server configs. Have you restarted sshd on the server? Are you able to login from a console? How about sshing from another machine?

share|improve this answer
Nop, I never toutched the server SSH config. I don't have physical access to the server ( and it's a virtual machine ). As far as I know, SSH connection work great from everywhere. –  FMaz008 Apr 2 '11 at 11:49
"As far as I know" doesn't help debug a situation like this. You really need to TRY to ssh in from another machine to see if you really have a working ssh server or not. The error above doesn't look like a key problem, so if it isn't your server you have some other client configuration issue. –  Caleb Apr 2 '11 at 11:59
Let me the time to get back to my job -- and try it, it's the weekend ! ;) –  FMaz008 Apr 3 '11 at 21:37
add comment

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.