{section:Interactive Singularity Jobs and condor_ssh_to_job}
Starting with HTCondor 8.8, =condor_ssh_to_job= and hence also interactive jobs use an =sshd= running directly on the execute node with user privileges. Since 8.8.10, most issue have been ironed out, and
connecting into the job happens using =condor_nsenter=, which is an =nsenter= -like tool to "enter" container namespaces in a generic way. This tool is spawned by the =starter= in parallel to =sshd=.

There are a few remaining issues related to X11 forwarding which can be worked around, and which are partially dependent on the utilised setup. These are discussed on this page.

{subsection:X11 forwarding}
X11 forwarding in general works by running =xauth= as a child of the =sshd= process on the execute node. =sshd= mostly prunes the environment before, setting a new DISPLAY variable to a forwarded X11 port. It then runs =xauth= which by default uses the user's home directory to store the X11 authorization information.

Two issues arise:
*: Since =condor_nsenter= does not run as a child of the =sshd=, but as a child of the =starter=, it can not pass on the =DISPLAY= environment variable to the user session.
*: In many cases, when containers are used, the actual users may not have a home directory on the execute node, or might not have it mounted inside the container. However, we cannot override the location to store the =.Xauthority= file with the environment variable =XAUTHORITY= since =sshd= prunes that.