When attempting SSH connections to Ubuntu 10.10 servers, you might encounter the cryptic error Server refused to allocate pty or its variant pty allocation request failed on channel 0. This fundamentally indicates the remote server's inability to create a pseudo-terminal (pty) during your SSH session initiation.

The error typically appears after successful authentication but before shell access. From the provided logs, we observe several important clues:

PAM unable to dlopen(/lib/security/pam_smbpass.so)
/home/florian/.zlogin:1: command not found: display_info

Based on the Ubuntu 10.10 environment and error patterns, these are the most probable causes:

• Broken PAM modules configuration
• Corrupted shell initialization files (.zlogin in this case)
• Resource limitations (maxproc, ptys, or open files)
• SSH server configuration issues

Try forcing non-interactive mode to bypass pty allocation:

ssh -T florian@mydomain.de /bin/bash --noprofile --norc

Or force a specific shell:

ssh -t florian@mydomain.de /bin/sh

Since you have recovery access, perform these steps from the repair environment:

# Mount the original root filesystem
mount /dev/sda1 /mnt

# Check shell initialization files
rm /mnt/home/florian/.zlogin
rm /mnt/home/florian/.zshrc

# Verify PAM configuration
chroot /mnt apt-get --reinstall install libpam-modules

# Check for resource limits
echo "session required pam_limits.so" >> /mnt/etc/pam.d/sshd

If the issue persists, enable verbose SSH logging:

ssh -vvv florian@mydomain.de

And check kernel messages for pty-related errors:

dmesg | grep pty

Modify your SSH server configuration (/etc/ssh/sshd_config):

# Ensure these settings exist
UsePAM yes
UsePrivilegeSeparation yes

---

When attempting SSH connections to my Ubuntu 10.10 VPS, I encountered persistent "Server refused to allocate pty" errors despite successful authentication. The system would display welcome messages but fail to provide an interactive shell, leaving me with a non-functional connection.

The error manifests in two similar forms:

Server refused to allocate pty
pty allocation request failed on channel 0

Log files reveal several interesting entries:

PAM unable to dlopen(/lib/security/pam_smbpass.so)
/lib/security/pam_smbpass.so: cannot open shared object file

First, try forcing a non-interactive session to bypass PTY allocation:

ssh -T user@hostname /bin/bash

If this succeeds, we can confirm the issue is PTY-specific. Another diagnostic command:

ssh -vvv user@hostname

This provides verbose output showing exactly where the PTY negotiation fails.

Several scenarios can trigger this behavior:

1. Incorrect shell configuration in /etc/passwd
2. Broken PAM modules (as seen in auth.log)
3. Resource limitations (max user processes reached)
4. Corrupted terminal devices in /dev/pts
5. SSH server configuration issues

1. Force command execution without PTY:

ssh -o RequestTTY=no user@hostname

2. Check and repair PAM configuration:

sudo apt-get install --reinstall libpam-modules

3. Verify shell assignment in /etc/passwd:

grep ^username /etc/passwd
usermod -s /bin/bash username

4. Check system resource limits:

ulimit -a
cat /proc/sys/kernel/pty/max

For deeper investigation, examine SSH server configuration:

sudo grep -i pty /etc/ssh/sshd_config

Check for any unusual Match rules or PTY-related restrictions. A temporary workaround might be:

sudo service ssh restart

In persistent cases, rebuilding the PTY subsystem may help:

sudo rm /dev/ptmx
sudo mknod -m 666 /dev/ptmx c 5 2
sudo service ssh restart

For Ubuntu 10.10 systems, remember this is an obsolete release with potential compatibility issues. Consider upgrading or migrating to a supported version. The PAM errors suggest missing dependencies that modern systems would handle differently.

When all else fails, booting into recovery mode (as mentioned in the original post) allows direct filesystem access to repair configuration files or reinstall critical packages.