How to fix PTY allocation request failed on channel 0 in SSH

Many SSH uses do not need an interactive terminal. If you only run a single command or pipe data, request no TTY with -T so the server has nothing to refuse:

ssh -T user@hostname 'uname -a'

The -T flag disables the TTY request; -t forces one. Be honest with yourself about which you need:

- If you only need to run a command, -T makes the warning disappear and the command runs.
- If you genuinely need an interactive shell (a prompt, top, vim, etc.), -T does NOT fix anything — it just stops asking for the TTY the server is refusing. You still get no shell. In that case the server policy is the real problem; continue below.

Note: Git over SSH and SFTP do not request a PTY, so they never produce this warning. If those fail, the cause is something else (auth, host key, path), not PTY allocation.

The refusal is almost always tied to the specific key the server accepted. Find out which one with verbose output:

ssh -v user@hostname 2>&1 | grep -i 'Offering\|Server accepts\|Authentications'

Look for the line Server accepts key: ... and note the path of the matching private key (often ~/.ssh/id_ed25519). You will check this key's entry on the server next. If you use an agent, ssh-add -l lists loaded keys.

This is the leading cause. On the server (or ask the server admin), look at the authorized_keys for the target account and find the line matching your public key:

cat ~/.ssh/authorized_keys

A restricted entry looks like one of these, with options BEFORE the key type:

command="/usr/bin/backup-only",no-pty ssh-ed25519 AAAA... deploy@ci
restrict ssh-ed25519 AAAA... ci-key
no-pty,no-X11-forwarding ssh-ed25519 AAAA... readonly

- no-pty explicitly forbids a TTY.
- restrict enables all restrictions, including no-pty, unless re-enabled with pty.
- command="..." forces a fixed command; an interactive shell is impossible regardless.

If this restriction is intentional (deploy/backup/Git key), it is working as designed — do not remove it just to get a shell. Use a different, unrestricted key or account for interactive access. If a TTY is genuinely required and authorized, the admin can add the pty option (and remove no-pty/forced command) for that line, then have you reconnect. Changing authorized_keys does not require restarting sshd.

If the key is not restricted, the daemon policy may be. On the server inspect the effective config:

sudo sshd -T -C user=youruser,host=$(hostname),addr=127.0.0.1 2>/dev/null | grep -iE 'permittty|forcecommand'
sudo grep -inE 'permittty|forcecommand|^match' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

- PermitTTY no disables TTY allocation. The default is yes.
- ForceCommand ... runs a fixed command instead of your shell, which also blocks an interactive session.
- A Match User, Match Group, or Match Address block can set either of the above only for certain users or sources, which is why some users get a shell and others do not.

If the restriction is intentional, leave it. If a TTY should be allowed, the admin edits the relevant block (or Match section) to PermitTTY yes and removes the blocking ForceCommand, validates with sudo sshd -t, then reloads:

sudo sshd -t && sudo systemctl reload ssh   # or: sudo systemctl reload sshd

Reload (not restart) keeps existing sessions alive.

If the target is a container, pod, or appliance that intentionally only allows specific commands, do not fight the SSH policy — use the platform's own interactive entry point:

# Docker
docker exec -it <container> /bin/bash

# Kubernetes
kubectl exec -it <pod> -- /bin/sh

# Cloud VM with no interactive SSH
# use the provider's serial/web console

These give you a real TTY without relying on the restricted SSH path.

These are rare and should only be checked after ruling out key and sshd policy. Diagnose first — do NOT remount or kill sessions on a live, multi-user host, as umount /dev/pts breaks every active terminal and can wedge logins.

Check the real PTY limit and current usage (modern Linux uses Unix98 PTYs; the default max is around 4096, not 256):

cat /proc/sys/kernel/pty/max     # configured maximum
cat /proc/sys/kernel/pty/nr      # currently allocated

If nr is close to max, you are genuinely out of PTYs; raise the limit deliberately (e.g. sysctl -w kernel.pty.max=8192) and investigate what is leaking terminals rather than mass-killing sessions.

On a broken/minimal container only, confirm devpts is present:

mount | grep devpts
ls -la /dev/pts

If it is missing inside an isolated container you control (not a shared host), it can be mounted with mount -t devpts devpts /dev/pts. Never unmount devpts on a host with active sessions.