Tools like tmux and screen are fantastic for doing work on remote systems: you can open up multiple sessions, fire off jobs, disconnect, and come back later, and things are still as you left them. However, if you use ssh-agent for credential forwarding, you've probably noticed a downside: after disconnecting and reconnecting, the environment variables that ssh and friends use to figure out how to talk to ssh-agent are now wrong.

There's a million different ways to solve this; here's my take on it:

Adding this to your .bash_profile (or .bashrc, depending on your local setup) will add aliases for both tmux and screen, which will save the four SSH-related environment variables you'll want to override inside of your terminal multiplexor to a file in your home directory. It also adds aliases for ssh, scp, and sftp, which forces the saved variables to be loaded prior to execution.

A quick random Linux administration tip: add the following three lines to root's .bashrc:

Once you do, future login sessions as root will be saved in a directory named .history in root's home directory, in the pattern:

2010-09-17.13:53:27.foohost.14379.foouser

Why would you want to do something like this? First, each shell/session is stored to it's own file, rather than interleaving into a single file in whatever order you might have exited them. Second, it tells you both when you started the session (by the filename) and when you ended it (by the timestamp on the file). Third, for systems administered by multiple people, it tells you who was su'd to root when the session occurred (or just displays root for console logins), so you know which admin "owned" that session.

The main downside here is that you lose the ability to see multiple sessions' worth of history in your history buffer, but for systems with multiple admins, I haven't missed it (as getting someone else's history when scrolling back has proven more annoying than helpful for me), but if you lean hard on your history, this might not be a net win for you.

Also, I'd suggest resisting the urge to treat this as an "audit log" of any kind; it's trivially bypassed, meaning that this is for teams that trust each other. Use it instead as a way of recreating the how and why of a change after (occasionally long after) it was made.

Kerberos as a site-wide authentication mechanism has it's benefits, but the software that's typically used to drive it is getting a little long in the tooth. ksu, the kerberized equivalent to su, is only a partial implementation of what su does; there's no argument to ksu that says "this is a login shell, please set up the necessary environment". Even su has a couple of failings; in particular, if you're an X user, you're probably familiar with how su - doesn't bring your X authentication data along for the ride.

So, I fixed both of those a while back, with a really ugly shell script. Just in case anyone else might find it handy, here it is: