文章作者：cloudsky
1.
假设现在 108 上运行了 sshd，以下涉及 Unix 的部分都是针对 108 来的
~/.ssh2/authorization 文件内容如下：
Key 107.pub
Key 108.pub
Key 106_1024.pub
# Key 106_2048.pub
# Key 106_512.pub
# Key 106.pub
这些入口顺序无关，有一个可以使用就可以成功登录。
这里指定的是本机作为 ssh server 时可以使用的公钥，注意这些公钥
不是本机的公钥，而是本机可以接受的 ssh client 的公钥。
~/.ssh2/ 目录下有如下文件：
107.pub
108.pub
106_1024.pub <-- 关键是这个文件
2.
以下涉及 F-Secure SSH 2.0.9 build 2 的部分都是针对 106 来的
D:\Program Files\Data Fellows\F-Secure\SSH\scz\ 目录下有如下文件：
106_1024
Identification.txt
Identification.txt 文件内容如下：
IdKey 106_2048
IdKey 106_1024 <-- 关键是这个文件
IdKey 106_512
IdKey 106
这些入口顺序无关，有一个可以使用就可以成功登录。
这里指定的是本机作为 ssh client 的时候使用的的私钥。
3.
从 98 下启动 F-Secure SSH
输入：
192.168.67.108
scz
public key 验证方式
如果一切正常的话应该已经登录成功
4. 如何得到 106_1024 和 106_1024.pub
运行 F-Secure SSH Wizard ，选择 DSA ，选择 1024 ，然后一路下去，
直到最后，会提示你这两个 key 文件的名字以及 Identification.txt
把 106_1024.pub 拖到 108 的 ~scz/.ssh2/ 目录下
选择 RSA 后我没有实验成功， 可以为空，Comment 不一定
是 username@localhost 的格式，任意。
可以为空，此时如果利用加密通道
d:
cd "D:\Program Files\Data Fellows\F-Secure\SSH\Program"
ssh2 -f -S -L 5858:192.168.67.108:23 -l scz 192.168.67.108
当上述三条命令在一个批处理中的时候，不再象 unix passwd 验证方式下
需要输入口令，只要点击快捷方式即可。但是使用加密通道的话，最后必然要
进入传统的 unix passwd 提问，不象单纯使用 ssh client 时，只要 public
key 验证通过就不再进入传统的 unix passwd 提问。
5. Unix下怎么办
cd /home/scz
ssh-keygen
这个命令会自动建立 /home/scz/.ssh2/ 子目录。子目录下会产生两个文件，
我改名为 108 和 108.pub 。
编辑 ~/.ssh2/identification
IdKey 108
此时可以用 ssh 0 测试，中途会提示 ， 是在执行
ssh-keygen 的过程中确定的。
如果把 108.pub 拖到 107 的 /home/scz/.ssh2/ 中，做相应设置后，可以从
108 上执行 ssh 192.168.67.107 ，效果和使用 F-Secure SSH 一样。
ssh-keygen -b 1024 -c
scz@server.venus.com.cn -o 108_linux_1024
会在~scz/.ssh2/下得到 108_linux_1024 和 108_linux_1024.pub 两个文件。
6.
~/.ssh2/hostkeys 子目录中会有 key_22_0.pub 这样的文件出现，这个文件是
执行 ssh 0 的时候自动产生的，表示在本机的 22 端口上运行有 sshd 。
D:\Program Files\Data Fellows\F-Secure\SSH\scz\hostkeys 下面也有类似的
文件，是使用 F-Secure SSH 连接服务器的时候自动产生的。
7.
SecureCRT 我没有实验成功，主要是不知道它生成密钥对的时候用的是 DSA 还是
RSA，没有让我选择，再就是没有找到指定 Identification.txt 文件的地方。
8.
如果这种 public key 认证失败，最后还会提示你 Unix Passwd。
无论如何，都已经是加密传输，不用担心监听。
9.
简单介绍一下原理，客户端连接服务器，根据 Identification.txt 告诉服务器它所
期待的公钥，服务器检查 authorization ，判断这个公钥是否被允许使用，如果允许，
服务器产生一定位数的随机数，用这个公钥加密，然后送回客户端，客户端用自己的
私钥解密，对得到的随机数产生一个 MD5 校验和，发回服务器，同时服务器也计算
一个 MD5 校验和，如果两者匹配，通过认证。
10.
一个公开的 BBS Server 使用的应该是 public key 验证方式，因为 passwd 验证方式对于
F-Secure SSH 来讲对应帐号必须拥有口令，而 bbs 帐号没有口令( 注意，没有口令和口令
为空完全是两个概念 )。实际上为了使用 public key 验证方式，将私钥散发到了所有用户，
而公钥保存在 ~bbs/.ssh2/ 子目录下，以前有文章介绍这种操作时将 公钥/私钥 一起散发
到了所有用户，不大好吧。虽然一般用户即使拿到了密钥对也无法解密数据，但我觉得完全
没有必要把公钥也散发下去。此外，如果你实在搞不定 public key 验证方式，就用 unix
passwd 验证方式也没有什么不好，给 bbs 一个口令 bbs 不就可以了，或者设置 bbs 口令
为空也一样嘛，实在搞不懂为什么一定要用操作那么复杂的 public key 验证方式。如果担心
用传统 unix passwd 验证方式会被监听，那可能是你有点误解，看我下面的原理介绍。
11.
ssh client 连接 ssh server 后，client发送自己的 public key 到 server ，server发送
自己的 hostkey.pub + serverkey.pub 到 client ，hostkey.pub 是 make install 的时
候自动生成的密钥对中的 public key ，serverkey.pub 每隔一段时间会自动产生一次，从来
都不保存到文件中，这个时间间隔是可以配置的，serverkey的长度也是可以配置的。client
根据 hostkey.pub + serverkey.pub 产生一个 sessionkey ，与前面的那些不同，sessionkey
不是用于公开密钥体系的，而是对称密钥体系的，client 和 server 协商好以后传输过程用
什么对称加密算法，无论用什么对称加密算法，密钥都是 sessionkey。因为 serverkey.pub
会不断改变，所以 sessionkey 也会不断改变。client 和 server 还可以协商使用什么压缩算
法。公开密钥体系首先就是用于完成对称密钥体系所使用密钥的传递，以后的所有会话都在对称
密钥体系保护之中。
接下来才是利用公开密钥体系进行验证。当所有 public key 验证失败后，会自动进入 unix
passwd 验证，注意，因为此时 sessionkey 已经发挥作用，所以无论如何都不会被监听去口
令。验证结束后，无论当初验证是用什么方式都无关了，sessionkey 会保护信息交换。关于这
点完全可以用协议分析工具自己去看看，很清楚的结论，要不就看看 ssh 的源代码。
./linuxkiller -a 80000000 -s server -t scz
当没有使用加密通道时，可以看到还原后的 telnet 界面，使用加密通道后全部是乱码。
对于 SecureCRT ，即使此时使用 unix passwd 验证方式，也是无法监听到口令明文的。
12.
可能出于安全考虑，root 用户不支持 public key 验证方式，始终会进入传统 unix passwd 提问。
