FPs

Articles with the ssh tag

echo 输出导致SCP 失效的问题

搭建了一个跳板机,强制使用密钥对登陆机器,同时需要用户在本地开启ForwardAgent,跳板机上创建SSH_AUTH_SOCK,透传私钥。然而常常有用户在本地没有正确配置,导致上了跳板机之后,再SSH 就会失败,于是我在跳板机的.bashrc 上写了一段检测脚本,如果变量$SSH_AUTH_SOCK 不存在,就引导用户去看Wiki,不要烦我啦!

用了一段时间,有用户发现scp 文件到跳板机时会失败,Google 一下:SCP doesn't work when echo in .bashrc?,怎么判断当前会话是scp?:Can I tell if I'm in an scp session in my .bashrc?

改下脚本:

if [ -n "$PS1" ] && [ -z $SSH_AUTH_SOCK ];then
   echo ""
   echo "创建SSH_AUTH_SOCK 失败!"
   echo "1.请在本机执行 ssh-add 添加私钥至 ssh-agent"
   echo "2.请在~/.ssh/config 配置:ForwardAgent yes"
   echo "详细帮助:wiki..."
   echo ""
fi

搞定!


Docker与虚拟机等的SSH权限管理控制解决方案

Docker和VM一类的云平台的权限控制如果采用常见的方式,把登录者的公钥写入~/.ssh/authorized_keys, 由于企业内部的人员流动和权限变更,往往不是十分便利。 特别是如果还选择把authorized_keys 打到镜像中的话,管理起来就会十分蛋疼。不过对于Docker这种容器,如果还需要开发登录进去进行Debug或者做其他操作的话,姿势上其实是不对的,不符合它的设计哲学,但是按照目前接触的国内使用Docker做内部云的厂商来看的话,大都是把Docker当作一个轻量级的VM来用而已,很多更是为了用Docker而用Docker。
这是题外话,如果是在企业内部的Server(Docker的容器、VM以及物理机),应该选择公共帐号登录,而不是给每个开发者或者运维人员都开一个个人帐号上去搞,这样不仅会十分混乱,而且员工离职之类的还好带来不少“遗留问题”。
一种解决思路是通过一些配置管理工具来管理Server的authorized_keys,例如Puppet、SaltStack、Ansible等。不过这需要运维人肉编辑配置文件,而且权限这种东西变更很频繁,所以更进一步是在这些配置管理工具只是进行开发,提供一个Web 服务作为权限控制平台。
另外一种解决思路是通过OpenSSH的AuthorizedKeysCommand选项,调用一个脚本,从远程的服务取得授权登者的公钥,具体做法可以参考前面链接的文章。
这种方法有个问题,如果远端权限管理的服务宕机了,可能是一个Web 服务,MySQL Server或者LDAP,都将造成通过这种方式授权的用户无法登录,所以必须保证该服务的稳定性。
另外应该禁止掉root登录,因为AuthorizedKeysCommand是作用于所有用户,包括root用户。将所有权限放在一个“篮子“里的话,除了得保证这个篮子的稳定性,还有安全性。
通过开发定制化一个Web服务,可以做更多事情,例如控制帐号的有效期,权限的批量开通等等。