4

Is there any way to control which pseudo-terminal (/dev/pts/*) a connection is given? For example, I have multiple thin clients each running individual terminal sessions to a RHEL server over SSH, I would like to configure something so that thin client A is always allocated /dev/pts/7 and thin client B is always /dev/pts/8. I have been trying to create a udev rule but udevinfo only returns "couldn't get the class device" when I run it against the terminal ID, I'm not sure how to create a rule if the device is not actually classed in udev.

Jeremy T.
  • 43

1 Answers1

5

Linux normally uses the Unix 98 pseudoterminal interface. Entries in /dev/pts are assigned outside the application's control. An application that wants to create a pseudoterminal (here the SSH server) opens /dev/ptmx, which allocates a pseudoterminal and returns a file descriptor to it. The pseudoterminal number (the number after /dev/pts/) determined when the pseudoterminal is allocated; it's tied to the index of the pseudoterminal in a kernel data structure.

(If you're curious, the kernel code is ptmx_open in drivers/tty/pty.c, which calls on devpts_new_index in fs/devpts/inode.c, which uses ida_get_new in lib/idr.c. This happens to return the first number available, though there is no guarantee that it will always do so.)

Neither the C API nor the kernel API allows the creator of the pseudoterminal to pass a parameter that would influence the result.

It may be possible to get a static pty by using the legacy BSD API that produces ptys of the form /dev/ptyNUM (master) and /dev/ttyNUM (slave). This would at a minimum require recompiling the SSH server without the HAVE_DEV_PTMX configure setting to force it to use BSD-style ptys. You would need to take care of permissions, though if SSH is the only user it might be a bit easier. Then you would need to patch OpenSSH to add some mechanism to tie a particular pty number to a particular client.

I would strongly recommend against this: it's a nonstandard configuration, requiring you to write some extra code. It's an extra maintenance effort and a security risk.

I don't see the point anyway. You can run last to see what client is currently logged in on each terminal.

Gilles 'SO- stop being evil'
  • 829,060
  • Thank you for the reply Giles. As I feared, the short answer here seems to be no. A nonstandard configuration, additional code, and potential risks are not the way I would want to do this.

    The reason for this is I support an application that users are currently accessing via very old dumb terminals over serial. The application has a feature which allows specific workstations to use specific devices, printers for example. The application can be configured so the terminal on tty1 always prints to printer A and terminal on tty2 always prints to printer B.

     – Jeremy T. Nov 02 '15 at 22:12
  • I'm trying to end of life the dumb terminals and upgrade to thin clients connecting over SSH. The problem is I can't guarantee which pseudoterminal ID a session is going to get and this is something that cannot easily be configured on the fly. The users are not technical at all and they do not even have OS access, they also power cycle their thin clients frequently so the pts designation is most certainly going to change at least once throughout the day. – Jeremy T. Nov 02 '15 at 22:12
  • @JeremyT. I think patching or, in a pinch, LD_PRELOADing the application to authorize by user rather than by terminal is your best bet. – Gilles 'SO- stop being evil' Nov 02 '15 at 22:21
  • All of that commentary really should have been in the actual question. – JdeBP Nov 03 '15 at 12:34