Automatically Invoking screen(1) on Remote Logins
If you routinely log into one or more remote systems using SSH, and have a flaky internet connection or an incompetent ISP, you probably already know about screen’s ability to detach and reattach sessions.
However, you still have to manually type screen -r to resume a detached session, each time — and sometimes you’ll forget, start working in an SSH session, get logged out, and lose your state.
Here’s the next step — automatic screen-sessions for any remote logins: RemoteLoginAutoScreen.
Matt Sergeant said,
April 20, 2006 @ 10:31 pm
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 msergeant@smtp-theodore.messagelabs.net ‘\’’screen -DR’\””‘
It’s kind of a bit lower tech, but it lets me login without screen if I really want to.
David Romano said,
April 20, 2006 @ 11:04 pm
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.
conall said,
April 20, 2006 @ 11:52 pm
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…
Aristotle Pagaltzis said,
April 21, 2006 @ 1:25 am
That‘s a whole lotta work. You can run
screenitself as a login shell (you then need to set your actual shell using theshellsetting in.screenrc, if memory serves).Pádraig Brady said,
April 21, 2006 @ 9:59 am
screen rocks! Here are some tips I wrote for it: http://www.pixelbeat.org/lkdb/screen.html
Andrew Oakley said,
April 21, 2006 @ 10:07 am
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.
Justin said,
April 21, 2006 @ 10:23 am
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.
Andre Uratsuka Manoel said,
April 21, 2006 @ 3:50 pm
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.
Bart said,
April 21, 2006 @ 4:39 pm
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.
http://www.harding.motd.ca/autossh/
Marc said,
April 23, 2006 @ 7:56 pm
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:
http://marc.abramowitz.info/archives/2004/12/04/gnu-screen-for-tivo-series-2/
Marc said,
April 23, 2006 @ 7:58 pm
I think to solve your SSHAUTHSOCK problem, you could run keychain:
http://www.gentoo.org/proj/en/keychain/index.xml
James said,
April 24, 2006 @ 1:57 am
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.
kaspar said,
August 26, 2006 @ 1:44 am
(as noted in the wiki): It would probably be better to check for
SSH_TTYthan forSSH_CLIENT, because otherwise it breaks scp andsftp(at least on my machines ;), becasue screens ncurses-interface is expecting a terminal, which both doesn’t provide, naturaly. There both setting theSSH_CLIENTvariable, but only direct ssh is settingSSH_TTY.Thanks for that snippet anyway, I’m currently using it on almost all of my machines :)
Justin said,
August 26, 2006 @ 2:10 pm
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…