1. Matt Sergeant
    Posted April 20, 2006 at 22:31 | Permalink

    I just have aliases for different boxes I want to log into, right up to including double-hop aliases (where I have to go via a box at work, which only works when I’m connected to the VPN):

    alias theodore=’ssh -t felony “ssh -t [email protected] ‘\”screen -DR’\””‘

    It’s kind of a bit lower tech, but it lets me login without screen if I really want to.

  2. Posted April 20, 2006 at 23:04 | Permalink

    I’m probably even more low-tech, or even just doing it wrong, but I have:

    screen -d -r

    as the last line in my ~/.bash_profile on the target computer. If there’s no screen active, it just warns “There is no screen to be detached.”, and spits me out to the shell. If I really want to start another screen session, then I just type screen, but otherwise I don’t have to worry about it.

  3. Posted April 20, 2006 at 23:52 | Permalink

    Nice tip.

    The one issue that still bugs me, mainly because I haven’t found a graceful way of doing it, is importing the $SSH_AUTH_SOCK variable set my my ssh key agent.

    If there was a relatively easy way to reassign it in every screen window of a session, it would mean I don’t have to wait for password prompts…

  4. Posted April 21, 2006 at 01:25 | Permalink

    That‘s a whole lotta work. You can run screen itself as a login shell (you then need to set your actual shell using the shell setting in .screenrc, if memory serves).

  5. Posted April 21, 2006 at 09:59 | Permalink

    screen rocks! Here are some tips I wrote for it: http://www.pixelbeat.org/lkdb/screen.html

  6. Posted April 21, 2006 at 10:07 | Permalink

    As a great man once said, There’s More Than One Way To Do It, and my simpler solution is to add:

    screen -x

    …to my .bashrc .

    -x attaches to your current screen session regardless of whether you have detached here or somewhere else, or even if you have screen attached somewhere else. The downside, of course, is that in the unlikely event of you running an attached session elsewhere on a visible display, anyone elsewhere also watching that display will also see everything you’re doing. But you’d have to be pretty dumb to leave a logged-in session on an unattended unlocked workstation anyway.

    The other problem is that this also only works if you have only one instance of screen. I prefer to nest my screen sessions (by using ^a-c to create new screens, then ^a-” to switch between screens; and then sshing to another machine within screen and starting a nested screen from there, accessible with ^a-a instead of ^a ), rather than detaching from one and reattaching to another, so this works for me.

  7. Posted April 21, 2006 at 10:23 | Permalink

    wow, TMTOWTDI certainly seems to apply ;) Thanks for all the comments, guys. Worth noting that there are the following bonus selling points for my approach:

    • you don’t need to use odd aliases on the client side, this’ll always happen when you SSH into that server

    • you don’t need to change your login shell. It may be just me, but that scares me ;) This is also why I have the “Screen failed!” failure case dealt with; I can foresee cases where bash works but screen doesn’t, for some reason.

    • it’ll support multiple simultaneous logins without them stepping on each other.

    • it’ll support non-interactive logins, which simply adding a line to ~/.bashrc will not (this is the PS1 check).

    The latter point in particular is a pet peeve of mine. Even the default /etc/profile file on Knoppix fails to deal with non-interactive logins correctly! Silly distros.

  8. Andre Uratsuka Manoel
    Posted April 21, 2006 at 15:50 | Permalink

    I used to have many screen sessions living forever, but sometime in the past, they just stopped because I started doing

    $ screen -ls (see list of screens) $ screen -Dr (attach screen and logs out other open sessions)

    I do that so mindlessly that I usually forget that I am doing it.

  9. Bart
    Posted April 21, 2006 at 16:39 | Permalink

    My solution to this is to run vncserver on the remote machine and autossh to reopen the ssh tunnel if the DSL line drops (which it doesn’t do nearly as often as it used to, thankfully). Then at worst I have to manually restart the VNC client.


  10. Posted April 23, 2006 at 19:56 | Permalink

    I love screen. I use it every day.

    In case you are interested in TiVo hacking, here’s a binary for screen that will run on a TiVo Series 2:


  11. Posted April 23, 2006 at 19:58 | Permalink

    I think to solve your SSHAUTHSOCK problem, you could run keychain:


  12. James
    Posted April 24, 2006 at 01:57 | Permalink

    For ssh, I run a script that grabs SSHAUTHSOCK, then I unset SSHAUTHSOCK in .screenrc, then in my .zshrc I export the saved value back. This does have the problem if your agent changes it’ll break in existing screens, but it’s good enough for me.

  13. Posted August 26, 2006 at 01:44 | Permalink

    (as noted in the wiki): It would probably be better to check for SSH_TTY than for SSH_CLIENT, because otherwise it breaks scp and sftp (at least on my machines ;), becasue screens ncurses-interface is expecting a terminal, which both doesn’t provide, naturaly. There both setting the SSH_CLIENT variable, but only direct ssh is setting SSH_TTY.

    Thanks for that snippet anyway, I’m currently using it on almost all of my machines :)

  14. Posted August 26, 2006 at 14:10 | Permalink

    kaspar — thanks for the note, I’ve added that to the main recipe.

    It is turning out to be extremely handy — by this stage, I’ve had multiple occasions where it’s saved me work dealing with a lost connection…