Getting a custom .bashrc available in ssh session

Question

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?

Answer 1

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.

Answer 2

It is useful to review the login process set out in man sshd to see the places where one can interject a user-specific environment into login. The process is:

1. print login and motd if a tty or unless ~/.hushlogin
2. if login on a tty; records login (note that LogLevel VERBOSE in sshd_config will show the connecting key used for logging in
3. if /etc/nologin exists, quit
4. change to run as normal user
5. sets up basic environment
6. reads ~/.ssh/environment if PermitUserEnvironment set in sshd_config
7. cds to user's home directory
8. if ~/.ssh/rc exists, runs it; else if /etc/ssh/sshrc exists, runs it... (mainly for X11)
9. runs user's shell or command.

It appears that using ~/.ssh/environment is the best way of controlling per-connection environment. However, as suggested by Jason, this can be done by setting an environment option in authorized_keys (if PermitUserEnvironment is enabled). The USER environment variable can be set at this time to a user other than the login user.

Overriding USER (and from there, the rest of their environment) might be the best approach from both the points of view logging on the host and the convenience of users connecting to it.

Unfortunately ssh certificates (I'm not talking about identity keys) don't allow one to specify environmental variables specifically in a connecting certificate. If this was provided, the certificate authority could generate client certificates with embedded