Ssh – Getting a custom .bashrc available in ssh session

bashgnu-screenremotessh

Currently, we have quite a lot of shared ssh logins to various servers, and my colleagues wouldn't like it if I fiddled with the default shell to much. I do however have quite a list of aliases and custom functions in my .bashrc that I'd like to follow me around.

Also, as some connections may be tricky, the first thing I like to do is start a screen session so if the connection gives up on me again, I can just log back and keep on going right where I left of.

Currently, I do this by appending a quite convoluted string to my ssh logins:

ssh -t -l sharedname someserver.example.com 'if [ -z \`find ~ -maxdepth 1 -iname '.wrikken_bashrc.sh' -mtime -14 \` ]; then scp wrikken@wrikken.example.com:.bash_remote.sh ~/.wrikken_bashrc.sh; fi; screen -h 2000 -DR wrikken bash --rcfile ~/.wrikken_bashrc.sh'

This works satisfactory (of course I never have to type it once set in the .bash_remote.sh file), but I seriously doubt whether this the / a right solution. Also, occasionally having to type my password to get an update of the .wrikken_bashrc.sh file is of course a pain. A personal account is unfortunately not an option.

In short: is there a better way of having my custom aliases & functions following me around across ssh logins?

Best Answer

Our outfit uses a similar setup on our development servers. If our developers need to run commands to control the server instance, they can use our 'assume' command --- which is simply a wrapper around ssh. Production servers are off limits to developers, unless we need to debug something serious.

Every developer that is authorized to login to the server instance's account has an entry in that server's authorized_keys(See the AUTHORIZED_KEYS FILE FORMAT section for details) file, but each authorized key has a flag that sets an environment variable unique to their username:

environment="SSHUSER=jason" ssh-rsa (BASE64-ENCODED-KEY) jason@localhost

In that server instance's .bashrc, I have a little snip of code:

USERHOME=$(eval "echo ~$SSHUSER")
if [ -f "$USERHOME/.client_bashrc" ]; then
    . "$USERHOME/.client_bashrc"
fi

Our developers can keep a .client_bashrc file (seperate from their .bashrc) with world-readable permissions in their home directory. Separating their .bashrc from .client_bashrc helps with security, since they can keep private definitions and environment variables in .bashrc. They can optionally put a line of code in their personal bashrc to simply include .client_bashrc, and keep aliases and definitions there that make working with the system easier. (This all assumes the user's home directory is accessible from the dev server.)

Warner makes a good point in his comment that this shared-username setup is against security best practices. Our system evolved from an account on a shared host years ago. We are only just now coming around to limiting the power of developer accounts, and moving to a system where developer actions are placed in an audit log.

Related Topic