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服务，可以做更多事情，例如控制帐号的有效期，权限的批量开通等等。