"Server refused to allocate pty" - how to mount devpts automatically?

Question

I have been using this box ubuntu 16.04 box hosted in vSphere every workday for last half a year. I'm connecting to it from Windows with putty/kitty. Today, I was greeted by the message similar to one in this question.

I'm not sure what caused it. Here is the message:

Authenticating with public key "imported-openssh-key"
Server refused to allocate pty
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.4.0-116-generic x86_64)

                                                                   * Documentation:  https://help.ubuntu.com
                                                                                                             * Management:     https://landscape.canonical.com
                                                                                                                                                               * Support:        https://ubuntu.com/advantage

                                                                                                                                                                                                             0 packages can be updated.
                                                                                                                                                                                                                                       0 updates are security updates.

I preserved the formatting as it was printed out.

This answer resolves the problem, but then I have to enter the command given every reboot:

mount devpts /dev/pts -t devpts

Adding an fstab line as shown at the link also given in one of the original question answers does not seem to change anything.

To be honest I have no idea why I did not need to mount this device up until now and then suddenly it stopped working and I need this mount.

What is the proper way to fix this issue for me so that I do not need to mount this after every reboot manually? Happy to provide logs or other diagnostics you might request.

Update

So In initially I dealt with the problem by rebuilding the box, but now it happened again and it started happening to other machines I manage too.

To follow Filipe's answer.

Running gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts gives

mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true

Running gzip -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move gives

# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev

Running with "debug" switch gives this output.

Anything else I can do to find the root cause of the issue?

Regenerating with sudo update-initramfs -c -k $(uname -r) did not produce any visible changes after reboot.

This is what I can see in mtab before and after mounting devpts manually:

>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
>sudo mount devpts /dev/pts -t devpts
>sudo cat /etc/mtab | grep devpts
devpts /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=666 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0

Answer 1

When I was getting "Server refused to allocate pty" it was a much simpler problem: my SSH server had the 'PermitTTY' option set to 'no'. (In the latest versions of OpenSSH, that line is normally commented out because 'yes' is the default. So as long as it's not manually set to 'no' you should be good.)

Use your favorite editor to double-check your sshd_config file.

sudo nano /etc/ssh/sshd_config

Make sure the 'PermitTTY' line is either absent, commented out, or manually set to 'yes', then restart your SSH server.

sudo service sshd restart

That might be all you need.

Answer 2

The /dev/pts filesystem is usually mounted by the initrd (a.k.a. initramfs) in Ubuntu.

The initramfs is a small filesystem that is loaded in memory when the kernel boots and sets up the system to switch into the real root filesystem, after setting up the basics and loading any kernel drivers needed to mount the real root.

You can find it under /boot, named initrd.img-* where the last part matches the kernel version.

It's an xz-compressed cpio archive.

You can look inside the "init" script that is first run when it's mounted by using the following command. The "grep" at the end of it looks at the line that mounts devpts:

$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout init | grep devpts
mount -t devpts -o noexec,nosuid,gid=5,mode=0620 devpts /dev/pts || true

That devpts is actually mounted in the root of the initramfs, so later on there's another step that moves it to the real root before switching to it. You can look at it here:

$ xz -dc /boot/initrd.img-$(uname -r) | cpio -i --quiet --to-stdout scripts/init-bottom/udev | grep move
# move the /dev tmpfs to the rootfs
mount -n -o move /dev ${rootmnt}/dev

If you want to extract the whole contents of the initrd, you can use:

# First go to an empty directory
$ mkdir -p /tmp/extract_initrd
$ cd /tmp/extract_initrd
$ xz -dc /boot/initrd.img-$(uname -r) | cpio -id

And then explore that tree...

If it seems something is wrong with your initramfs, you can try to re-generate it using the update-initramfs command, like so:

$ sudo update-initramfs -c -k $(uname -r)

Watch out for any errors in the output of this command, they might give you a clue of something that might be going wrong...

Another possibility is to enable debug logging in the initrd. To do that, add "debug" to the kernel command-line and reboot. Then look at the file /run/initramfs/initramfs.debug after the system boots, that will contain the messages printed by the initrd scripts. See here for more details on initramfs debugging.

Answer 3

I had a similar issue at https://serverfault.com/a/934030/33095

Permissions were different than what was expected, but was able to fix that using:

sudo mount -o remount /dev/pts
sudo grep devpts /proc/mounts

devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0