SSH公钥认证的问题

在Gitolite上配置了公钥，对应的私钥放在用户A的.ssh目录下可以认证，而用户B的目录下认证则失败。区别在于用户A的.ssh目录下只有私钥id_rsa，而用户B的目录下除了私钥，还有一个老的公钥id_rsa.pub，这和私钥是不配对的。

经过对比，这俩用户下的私钥是一模一样的，.ssh和id_rsa的权限也都是正确的。

用ssh的-v参数，看到这两个用户的公钥认证的输出信息稍微有所不同。用户A的：

debug1: Next authentication method: publickey
debug1: Trying private key: /home/userA/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentication succeeded (publickey).

用户B的：

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/userB/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp ef:a2:55:bc:86:1f:0a:48:e1:45:fc:b5:da:ca:70:e0
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Trying private key: /home/userB/.ssh/id_dsa

用户A开始打出的是：Trying private key，而用户B打出的是：Offering RSA public key。

最后实在看不出配置哪里有不同，就把用户B下面不相关的公钥id_rsa.pub移出去，然后认证成功了。因为我认为公钥不重要，认证看的是私钥，所以没有管那个无效的公钥。结果罪魁祸首竟然就是这个无关的公钥。

看来OpenSSH如果看到公钥文件名，则从公钥检查起，而这样不配对的私钥就认证失败了。而如果只放私钥，反而会成功。从这个文件里面也能验证这一点。

SSH的公钥登录问题

今天公司有个妹纸的Git不能用了，提示输入密码。我查了Gitosis配置没问题，再去找她，原来她自己照着从网上搜来的一篇博文搞公钥登录，没有搞成。

Git不能用，那就说明Gitosis中的公钥和客户端的私钥不配对，她的确承认应该是把私钥搞乱了。折腾好几次，SSH的公钥登录就是不成功，服务器提示输入密码。最后试着把服务器上她的authorized_keys文件的权限由664改为600，然后就可以了。这个文件别人的确是不应该有写权限的，否则会有安全问题，不过SSH的文档里面貌似没有说权限错误会拒绝登录。

郁闷的是该同学开始没告诉我自己做了什么操作，害我从Gitosis的配置查起，后来才告诉我自己折腾了什么。

SSH登录太慢

从CentOS 6.2用ssh连接Solaris 10很慢，加上-v参数后看到：

debug1: Authentications that can continue: gssapi-keyex,gssapi-with-mic,publickey,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
Cannot determine realm for numeric host address
debug1: An invalid name was supplied
debug1: An invalid name was supplied
debug1: Next authentication method: publickey
......

是两个GSSAPI的认证等待失败导致登录很慢。看了Solaris上的sshd_config(4)，GSSAPIAuthentication默认打开，CentOS上的ssh_config(5)中GSSAPIAuthentication默认也是关闭，但是/etc/ssh/ssh_config中却打开了该选项，这导致ssh尝试了GSSAPI认证。

解决办法很多，要么在服务器端的sshd_config中关掉该选项，要么在客户机的~/.ssh/config或者ssh_config中关掉，或者用ssh -o GSSAPIAuthentication=no来登录。真是：*nix is like a box of chocolate, you never know what you are gonna get.

SSH上不去

新建了个测试用户，结果远程登录上不去。看了这个用户没有家目录，还以为这样不行呢。但建了也上不去。是不是设置了knockd？没有。是不是端口改成了不是22的？也不是。最后打开IBM DW上的《保护 SSH 的三把锁》这篇文章，因为我照着这个配置过。一看还有一把锁是用PAM限制登录用户，原来我用PAM设置了两个用户能用SSH登录上来。有时候做了一些不常用的配置，时间长了就记不清了。出了问题想不起来就有点麻烦了。

SSH Tunnel不能自动启动，2

上次研究了SSH Tunnel不能自动启动的问题，没想到用了autossh后还是有问题，进入桌面后没有建立起来。于是用

ssh -v -N -D 7070 user@1.2.3.4 &>out.ssh

的命令来观察。ssh的-v参数打开详细输出，&>out.ssh把stdout和stderr都重定向到out.ssh文件。

观察发现out.ssh的如下内容：

debug1: Connecting to 1.2.3.4 [1.2.3.4] port 22.
debug1: connect to address 1.2.3.4 port 22: Network is unreachable
ssh: connect to host 1.2.3.4 port 22: Network is unreachable

如果在启动ssh命令前，加上sleep 5再试验，就发现网络可以正常连接。本文通过观察ssh的输出，再次验证了原文中的假设是正确的。