SSH的公钥

背景

在开发中,经常在客户端生成密钥和公钥(ssh-keygen -t rsa),将生成的公钥内容追加到服务器的~/.ssh/authorized_keys文件中,并重新加载服务器sshd服务。其中gitolite就是使用这种机制。但是我们在配置时候,经常会遇到问题,配置完成之后,还需要输入密码,下面针对这个问题,进行分析排查。

打怪兽

怪兽显形

还记得年轻时候,搭建了个gitolite服务,近期新配了本本,安装openSUSE系统,在原来Ubuntu上拷贝密钥到新本本发现无法正常clone,需要输入密码,由此展开一场惊心动魄的排查战争。

怪兽跟踪

第一步,gitolite

由于是在gitolite上引起的错误,自然而然谷歌关于gitolite相关帖子,发现内容内容针对性不多,而且大部分是权限。仔细再次阅读gitolitereadme,会发现其实是通过在~/.ssh/authorized_keys里面加入公钥来达到通信,那么简单,应该就是ssh连接出现问题了。

在此期间发现ssh troubleshooting and tips

This is a quick checklist:

  • Make sure you’re being asked for a password and not a passphrase. Do not confuse or mistake a prompt saying Enter passphrase for key '/home/sitaram/.ssh/id_rsa': for a password prompt from the remote server!
    When you create an ssh keypair using ssh-keygen, you have the option of protecting it with a passphrase. When you subsequently use that keypair to access a remote host, your local ssh client needs to unlock the corresponding private key, and ssh will probably ask for the passphrase you set when you created the keypair.
    You have two choices to avoid this prompt every time you try to use the private key. The first is to create keypairs without a passphrase (just hit enter when prompted for one). Be sure to add a passphrase later, once everything is working, using ssh-keygen -p.
    The second is to use ssh-agent (or keychain, which in turn uses ssh-agent) or something like that to manage your keys. Other than discussing one more potential trouble-spot with ssh-agent (see below), further discussion of ssh-agent/keychain is out of scope of this page.

  • Ssh is very sensitive to permissions. An extremely conservative setup is given below, but be sure to do this on both the client and the server:

    1
    2
    3
    4
    > cd $HOME
    > chmod go-rwx .
    > chmod -R go-rwx .ssh
    >
  • Actually, every component of the path to ~/.ssh/authorized_keys all the way upto the root directory must be at least chmod go-w. So be sure to check / and /home also.

  • While you’re doing this, make sure the owner and group info for each of these components are correct. ls -ald ~ ~/.ssh ~/.ssh/authorized_keys will tell you what they are.
  • You may also want to check /etc/ssh/sshd_config to see if the “git” user is allowed to login at all. For example, if that file contains an AllowUsers config entry, then only users mentioned in that line are allowed to log in!
  • While you’re in there, check that file does NOT have a setting for AuthorizedKeysFile. See man sshd_config for details. This setting is a show stopper for gitolite to use ssh.
  • Some OSs/distributions require that the “git” user should have a password and/or not be a locked account. You may want to check that as well.
  • If your server is running SELinux, and you install gitolite to /var/gitolite or another location unsupported by default SELinux policies, then SELinux will prevent sshd from reading .ssh/authorized_keys. Consider installing gitolite to /var/lib/gitolite, which is a supported location by default SELinux policies.
  • If all that fails, log onto the server as root, cd /var/log, and look for a file called auth.log or secure or some such name. Look inside this file for messages matching the approximate time of your last attempt to login, to see if they tell you what is the problem.

第二步,ssh配置

在此期间做了几件事:

  • openSUSE上安装虚拟机Ubuntu并进行clone,发现正常
  • openSUSE上生成密钥,并拷贝到Ubuntu上,发现正常

由此判断,问题在openSUSE系统配置上,检查/etc/ssh/ssh_config文件配置,并与Ubuntu配置进行判断,并没有发现特殊配置,且修改为一致也无法解决此问题。

进行大规模尝试,包括将.ssh权限修改为0700authorized_keysid_rsa.pub权限修改为0644id_rsa0600,但是不是权限问题。
进行排查是否是群组权限问题,通过修改用户群组,并未发现问题。

第三步,大招

经过上面进行解决之后,均无法发现问题,陷入疑惑,并进行咨询,排查信息。因为gitolite其实也是通过ssh来进行验证,那么其实是可以通过下面代码来进行验证并查看记录:

1
2
ssh -vvt git@xxx.xxx.xxx.xxx
ssh -v git@xxx.xxx.xxx.xxx

排查发现,会默认寻找id_rsa进行公钥验证,而在ubuntu上,会对公钥进行轮询并进行验证,在openSUSE上将密钥修改为id_rsa成功!

原来是这个基本问题,被自己蠢哭了!!!

解决

简单处理,新增~/.ssh/config文件,并针对各个key进行配置,上配置模板。

1
2
3
4
5
6
Host github.com  ##主机别名
Hostname github.com ##主机真实地址
PreferredAuthentications publickey
IdentityFile ~/.ssh/git/tudouya_id_rsa
User user
Port port

或者使用ssh-agent来解决。

配置

ssh配置文件为/etc/ssh/ssh_configsshd配置/etc/ssh/sshd_config,参数配置:

Port 22
“Port”设置sshd监听的端口号。

ListenAddress 192.168.1.1
“ListenAddress”设置sshd服务器绑定的IP地址。

HostKey /etc/ssh/ssh_host_key
“HostKey”设置包含计算机私人密匙的文件。

ServerKeyBits 1024
“ServerKeyBits”定义服务器密匙的位数。

LoginGraceTime 600
“LoginGraceTime”设置如果用户不能成功登录,在切断连接之前服务器需要等待的时间(以秒为单位)。

KeyRegenerationInterval 3600
“KeyRegenerationInterval”设置在多少秒之后自动重新生成服务器的密匙(如果使用密匙)。重新生成密匙是为了防止用盗用的密匙解密被截获的信息。

PermitRootLogin no
“PermitRootLogin”设置root能不能用ssh登录。这个选项一定不要设成“yes”。

IgnoreRhosts yes
“IgnoreRhosts”设置验证的时候是否使用“rhosts”和“shosts”文件。

IgnoreUserKnownHosts yes
“IgnoreUserKnownHosts”设置ssh daemon是否在进行RhostsRSAAuthentication安全验证的时候忽略用户的“$HOME/.ssh/known_hosts”

StrictModes yes
“StrictModes”设置ssh在接收登录请求之前是否检查用户家目录和rhosts文件的权限和所有权。这通常是必要的,因为新手经常会把自己的目录和文件设成任何人都有写权限。

X11Forwarding no
“X11Forwarding”设置是否允许X11转发。

PrintMotd yes
“PrintMotd”设置sshd是否在用户登录的时候显示“/etc/motd”中的信息。

SyslogFacility AUTH
“SyslogFacility”设置在记录来自sshd的消息的时候,是否给出“facility code”。

LogLevel INFO
“LogLevel”设置记录sshd日志消息的层次。INFO是一个好的选择。查看sshd的man帮助页,已获取更多的信息。

RhostsAuthentication no
“RhostsAuthentication”设置只用rhosts或“/etc/hosts.equiv”进行安全验证是否已经足够了。

RhostsRSAAuthentication no
“RhostsRSA”设置是否允许用rhosts或“/etc/hosts.equiv”加上RSA进行安全验证。

RSAAuthentication yes
“RSAAuthentication”设置是否允许只有RSA安全验证。

PasswordAuthentication yes
“PasswordAuthentication”设置是否允许口令验证。

PermitEmptyPasswords no
“PermitEmptyPasswords”设置是否允许用口令为空的帐号登录。

AllowUsers admin
“AllowUsers”的后面可以跟着任意的数量的用户名的匹配串(patterns)或user@host这样的匹配串,这些字符串用空格隔开。主机名可以是DNS名或IP地址。

后记

SSH是很强大而安全的工具,使用它,了解它,完成各种任务!!!

REF

ssh troubleshooting and tips
Managing Multiple SSH Keys » Robot Goblin
SSH 安全性和配置入门
SSH 上传公钥到服务器后还需要密码 » 社区 » Ruby China
如何生成ssh key以及使用多个ssh key | php101