When physically connected to my "server" (typing commands from the desktop of a mid 2006 iMac), it gives the following output:

mac~$ screen -ls
No Sockets found in /var/folders/ht/rhhsw0515vl_ym59683911400000gn/T/.screen.

bash$ screen -dmS foo
bash$ screen -ls
There is a screen on:
    4250.foo    (Detached)
1 Socket in /var/folders/ht/rhhsw0515vl_ym59683911400000gn/T/.screen.


Which is the behaviour one would expect. However, when executing the same commands over RSA-authenticated ssh the screen -dmS foo command doesn't seem to work:

remote-bash$ screen -ls
No Sockets found in /var/folders/h4/_8scfsb54kd3mm7q6n9lq8nc0000gn/T/.screen.

remote-bash$ screen -dmS foo
remote-bash$ screen -ls
No Sockets found in /var/folders/h4/_8scfsb54kd3mm7q6n9lq8nc0000gn/T/.screen.


Upon trying the standard, option-free screen command, the entire shell hangs and can't be exited with ^C.

Note that I can see, attach to and kill screens launched on the server, but I can't launch them over ssh.

Is there an explanation for this inconsistency, or is the issue peculiar to my machine?


The first thing that comes to my mind is that the shell screen is launching when connected via ssh dies immediately for some reason. Try using

screen -LdmS foo

instead and then look at the contents of the file screenlog.0 to find out.

EDIT after OP comment:

it seems screen isn't able to start a shell. I guess your ssh server isn't setting the SHELL environment variable properly or your shell needs something else to run that your ssh server does not provide by default. Please check the output of

echo $SHELL

and then try to run the same shell by hand (i.e. execute the command you see in the output).

Also, there could be permission problems in the terminal. Under my OSX 10.9.5, just now, that is /dev/ttys000, in your case you can use the who command to find out yours. Screen needs write permission for the current user to that terminal. Now I read in your comment that the permissions in your case are:

crw--w---- 1 sandersfamily tty 16, 1 7 Mar 23:31 ttys001

Is "sandersfamily" the user you are logging in with via ssh? If not, then that's the problem.

  • I ran the command, but running ls -a | grep screen returned nothing in the ~/ or the / directories. – catalogue_number Feb 28 '16 at 7:30
  • echoing $SHELL returns /bin/bash only – catalogue_number Feb 28 '16 at 13:43
  • what if you launch a /bin/bash yourself instead of screen? Does it work? – Lucio Crusca Feb 28 '16 at 14:23
  • launching /bin/bash works absolutely fine, it's just screen that behaves strangely. – catalogue_number Feb 28 '16 at 22:08
  • What about the terminal permission bits? (see new edit in my reply). – Lucio Crusca Feb 29 '16 at 9:06

I've found the problem!

Turns out that, for some reason or another, screen cannot write without PAM being enabled. I'd previously read that, even if PasswordAuthenticaitonand ChallengeResponseAuthentication are set to no, PAM is still a vulnerability, so I disabled it in the /etc/sshd_config file.

All it took was to change UsePAM no to UsePAM yes in /etc/sshd_config, and the command works as expected. I don't know if there's a way to use screen without PAM being enables, but I don't believe it's an especially grave security issue for my purposes.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.