目前，我们有很多共享的 sshlogin到不同的服务器，而我的同事也不会喜欢它，如果我用默认的shell弄的太多了。 然而，我在.bashrc中有很多别名和自定义函数，我想跟着我。
另外，由于某些连接可能会非常棘手，所以我想要做的第一件事就是开始一个屏幕会话，如果连接再次放弃，我可以重新login并继续往下走。
目前，我通过添加一个相当复杂的string到我的SSHlogin：
ssh -t -l sharedname someserver.example.com 'if [ -z \`find ~ -maxdepth 1 -iname '.wrikken_bashrc.sh' -mtime -14 \` ]; then scp [email protected]:.bash_remote.sh ~/.wrikken_bashrc.sh; fi; screen -h 2000 -DR wrikken bash --rcfile ~/.wrikken_bashrc.sh'
这个工作令人满意（当然我从来没有必要在.bash_remote.sh文件中设置一次），但是我非常怀疑这是否是正确的解决scheme。 另外，偶尔不得不input我的密码才能获得.wrikken_bashrc.sh文件的更新，这当然是一件痛苦的.wrikken_bashrc.sh 。 不幸的是，个人帐户不是一个选项。
简而言之：有没有更好的方式让我的自定义别名和函数在我身边绕过sshlogin？
我们的服装在我们的开发服务器上使用类似的设置。 如果我们的开发人员需要运行命令来控制服务器实例，那么他们可以使用我们的“假设”命令 – 这只是ssh的一个包装。 生产服务器对开发者是有限制的，除非我们需要debugging一些严重的事情。
每个有权login到服务器实例帐户的开发人员在该服务器的authorized_keys 文件中都有一个条目（ 请参阅AUTHORIZED_KEYS FILE FORMAT部分以获取详细信息 ）文件，但是每个授权密钥都有一个标志，用于设置用户名唯一的环境variables：
environment="SSHUSER=jason" ssh-rsa (BASE64-ENCODED-KEY) jason@localhost
在那个服务器实例的.bashrc中，我有一小段代码：
USERHOME=$(eval "echo ~$SSHUSER") if [ -f "$USERHOME/.client_bashrc" ]; then . "$USERHOME/.client_bashrc" fi
我们的开发人员可以在他们的主目录中保存一个.client_bashrc文件（与.bashrc分开），具有世界可读的权限。 将.bashrc与.client_bashrc分离有助于提高安全性，因为它们可以将私有定义和环境variables保存在.bashrc中。 他们可以select在其个人bashrc中放入一行代码，只需包含.client_bashrc，并在其中保留别名和定义，从而使系统更容易工作。 （这一切都假定用户的主目录可以从开发服务器访问。）
华纳在他的评论中提到了这个共享用户名设置违反安全最佳实践。 我们的系统多年前从共享主机上的帐户演变而来。 我们现在才刚刚开始限制开发人员帐户的权力，并转而将开发人员操作放在审核日志中。
查看man sshd中设置的login过程以查看login过程中可以插入用户特定环境的位置是非常有用的。 这个过程是：
~/.ssh/environment 看来使用〜/ .ssh / environment是控制每个连接环境的最好方法。 但是，正如Jason所build议的那样，这可以通过在authorized_keys中设置一个环境选项来完成（如果PermitUserEnvironment被启用）。 此时可以将USER环境variables设置为login用户以外的用户。
覆盖用户（从那里，其余的环境）可能是从主机上的观点logging和连接到用户的便利性的最佳方法。
不幸的是，ssh证书（我不是在谈论身份密钥）不允许在连接证书中专门指定环境variables。 如果提供，则证书颁发机构可以生成embedded式客户端证书