出于管理不同服务器以及自己几个 VPS 的需要，我都会把这些 SSH 密钥保存到自己的 KeePass 密码数据库中，KeePass 软件安装了 KeeAgent 插件之后，可以在用户需要登录服务器时方便地自动加载 SSH 密钥。KeeAgent 同时支持 PuTTY 和 OpenSSH 格式的私钥，而且支持 Windows / Linux / Mac 系统。我在平时使用中无论用 Windows 下的 PuTTY / SecureCRT / XShell 软件还是 Linux 下用 ssh 命令都能愉快的自动加载 KeeAgent 保存的 SSH 证书，这里也强烈建议各位将 SSH 密钥用 KeeAgent 插件保存到 KeePass 密码库中。

不过自从将工作的电脑系统升级到 Windows 10 之后，虽然我使用 Win10 系统自带的 Bash shell 的场合也越来越多了（原来的 MSYS 和 Cygwin 环境基本很少开启了），但也发现 Win10 Bash 自带的 ssh 命令却不支持 KeeAgent 插件，仍然需要手工选择私钥文件或者输入密码登录服务器。

KeeAgent 在 Linux / Mac 系统下是支持原生的 SSH agent 的，SSH agent 使用的是基于 Unix socket 文件工作方式，也因此 Linux / Mac 系统下的 ssh 命令直接就能自动加载 KeeAgent 保存的密钥。

虽然 Win10 WSL（Windows Subsystem for Linux）子系统内部是支持 Unix socket 文件的，但 WSL 子系统外的 Windows 版本 KeeAgent 插件要想支持 WSL 内部的 socket 文件就不太容易了，还需要通过别的方法来绕过这个限制。

msysGit to Unix socket 代理

看了 KeePass 的 KeeAgent 插件选项可以看到该插件是支持 Cygwin 和 msysGit（现在已更名为 Git for Windows）兼容的 socket 文件的，这样原来的 Cygwin 和 MSYS 用户也可以自动加载 KeeAgent 中保存的密钥，例如我的 KeeAgent 配置如下：

虽然 KeeAgent 不能直接支持 Win10 WSL 子系统内的 Unix socket 文件，但已经有人写了个 msysGit socket to Unix socket 的 Python 代理程序，借助此 msysgit2unix-socket.py 代理程序就可以让 Win10 Bash shell 通过 SSH agent 加载 KeeAgent 中的密钥咯。

该代理程序启动时会创建一个用于 SSH 认证的 Unix socket 文件，然后 TCP 连接到本地 KeeAgent 插件创建的 msysGit socket 文件，收到 ssh、scp 等命令的认证请求后将数据转发到 KeeAgent 插件，最后将结果返回到 Unix socket 文件。代理程序的工作机制大概如我粗画的这张图：

不过我在使用中还是发现该代理程序存在一点小问题：

第一次 SSH 认证可以通过 KeeAgent 插件返回成功，后续再有新的认证请求时却会一直卡住。调试之后发现前面的认证请求完成之后，虽然 ssh 命令至 Unix socket 文件的连接关闭了，但是代理程序至 msysGit socket 文件的连接却一直保持着未关闭，这样新的认证请求将无法正常从 KeeAgent 插件获取有效的证书数据。

为了解决这个问题，我 fork 了这个 msysGit to Unix socket 代理程序，并做了小改动，也放到了 Gist 上：

https://gist.github.com/zohead/b3cbb709fdfd2c0da31bff1b3f436af7

使用 socket 代理程序

首先下载 msysgit2unix-socket.py 代理程序，可以直接放到 Win10 Bash shell 用户主目录中，然后编辑 ~/.bashrc 文件增加下面这几行：

export SSH_AUTH_SOCK="/tmp/.ssh-auth-sock"
if [ -s /mnt/d/msys/keeagent.sock ]; then
	~/msysgit2unix-socket.py /mnt/d/msys/keeagent.sock:$SSH_AUTH_SOCK 2>/dev/null
	trap "~/msysgit2unix-socket-exit.sh $$" EXIT
fi

这样运行 bash 命令后会自动启动该程序，msysgit2unix-socket.py 程序启动之后会自动转为后台守护进程，并在 /tmp 目录（实际在 Windows 系统的 C:\Users\user\AppData\Local\lxss\rootfs\tmp 目录下）下生成兼容 ssh 命令的 socket 文件，而且如果开启多个 Bash 会话也不会影响，只会在后台保持运行一个 msysgit2unix-socket.py 代理程序。

上面内容第二行的 /mnt/d/msys/keeagent.sock 路径就是 KeeAgent 选项中的 Create msysGit compatible socket file 文件路径，请根据情况自行修改。

我增加的一行 trap 退出操作是为了能在最后一个 Win10 Bash 会话退出之时能执行自定义的清理脚本以删除 msysgit2unix-socket.py 程序产生的临时文件，不然下次再开启 Bash 运行 msysgit2unix-socket.py 程序时会因为已经存在临时的 socket 及 PID 文件导致程序退出。

我增加的 msysgit2unix-socket-exit.sh 脚本程序也非常简单：

#!/bin/sh
BASHPIDS=`pidof bash -o %PPID -o $1`
[ "x$BASHPIDS" != "x" ] && exit 0
rm -f /tmp/msysgit2unix-socket.pid /tmp/.ssh-auth-sock

这里使用 pidof 命令判断当前退出的是不是最后一个 Win10 Bash 会话（通过参数忽略了父 bash 进程和脚本程序自身进程），如果是最后一个 Bash 会话则删除 msysgit2unix-socket.py 程序产生的临时文件。

当然你也可以去掉增加的清理脚本，直接在 ~/.bashrc 文件中判断 msysgit2unix-socket.py 程序运行状态并删除之前产生的临时文件：

export SSH_AUTH_SOCK="/tmp/.ssh-auth-sock"
if [ -s /mnt/d/msys/keeagent.sock ]; then
	pgrep -f msysgit2unix-socket.py >/dev/null 2>&1
	if [ $? -ne 0 ]; then
		rm -f /tmp/msysgit2unix-socket.pid /tmp/.ssh-auth-sock
		~/msysgit2unix-socket.py /mnt/d/msys/keeagent.sock:$SSH_AUTH_SOCK 2>/dev/null
	fi
fi

这样修改之后就能在 Win10 Bash 里畅快地使用 ssh、scp 等命令通过 KeeAgent 插件自动登录服务器进行管理咯，祝大家在这个看起来不太冷的 12 月玩得开心 ^_^。

之前为了能在 Windows 上使用 Bash 等类似 Unix（Linux）系统的体验，我都是安装了 Cygwin、MSYS 等运行环境，都体验上都存在一些问题：Cygwin 上的程序基本都需要重新编译出基于其运行库（cygwin1.dll）的版本，MSYS 虽然提供了 Linux 下常用的开发工具链、移植过的运行库等等，但基本还是受限于 Windows API 本身的。

当我看到 Windows 10 Build 14316 内部预览版时爆出的 Bash on Ubuntu 功能之后还是比较期待的，因为微软并不是以虚拟机的方式运行 Ubuntu 系统，而是直接集成了新的 Windows Subsystem for Linux 子系统，这样能直接在 Bash on Ubuntu 环境里编译运行 Linux 程序还是非常方便的。

考虑到预览版稳定性的问题，我一直没有加入 Win10 Insider 预览体验会员，这几天看到 Win10 Redstone 1 年度更新到来之后终于可以直接体验了。虽然我使用的 Win10 企业版一直接收不到更新推送，而且使用微软官方的 Media Creation Tool 也无法在企业版上更新，但还好还是可以直接下载 Redstone 1 企业版的 iso 进行更新。

安装体验

Win10 年度更新的持续数小时的痛苦安装过程这里就不表了，更新完成后首先在设置中开启开发者支持，然后在 控制面板 - 程序和功能 中开启 Windows Subsystem for Linux 功能，开启之后需要重启系统，重启之后在命令行中运行 bash 命令下载安装，根据你的网络情况可能又需要一两个小时（强烈建议挂代理的），安装完成之后会提示配置用户，接着就可以正常启动 Bash on Ubuntu 了：

第一步就可以先运行 sudo apt-get update 更新 Ubuntu 软件仓库，看起来一切正常：

另外可以确认下 Windows 10 上运行的 Ubuntu 子系统的基本情况：

从上面的截图可以看出 Bash on Ubuntu 会把所有 Windows 分区都挂载到 /mnt 目录下方便使用（这点和 Cygwin 的 /cygdrive/c 以及 MSYS 的 /c 路径有点类似哦），默认运行的是 Ubuntu 14.04 LTS 系统，用户看到的 Linux kernel 是 3.4.0 版本。

接着就可以安装运行一些常用的 Linux 命令了，awk、sed、svn、git 等和系统内核关系不大的命令都能正常工作，ifconfig 和 ping 等命令会运行失败，体验一圈下来还是能满足我的使用需求的。

rsync 备份性能测试

我之前写过一篇文章 rsync在 Linux/cygwin/msys 环境下的备份性能对比 对比 Linux 原生的 rsync 命令和 Windows 上几种常见的非原生 rsync 实现的备份性能，结果不出意外 Linux 原生 rsync 的效果是最好的。

现在既然 Win10 已经支持了还算完整的 Ubuntu 子系统，那么我就可以拿 Ubuntu 子系统里的 rsync 命令来测试一下备份文件的性能到底如何了，而且这里值得一提的是 Bash on Ubuntu 安装好之后就已经自带 rsync 命令了（没有也可以妥妥的 apt-get 自动安装哦）。

先看看 Bash on Ubuntu 自带的 rsync 命令是 3.1.0 版本的，可以直接和我们目前使用的存储服务器配合测试：

为了对比方便我在相同的客户端上分别运行 RHEL6 Linux 系统和开启了 Bash on Ubuntu 的 Win10 系统使用 rsync 命令进行文件备份的上传和下载性能测试，存储服务器上运行的是标准 rsync 服务器（没有开启 SSH 用户验证）。

测试中也使用和上面的备份性能对比文章相似的配置，服务器使用 24 个 SATA 盘建立 RAID0 磁盘阵列做底层存储，客户端和服务器之间都是千兆网络，客户端上的文件读写都使用内存文件系统（Linux 上使用 tmpfs，Windows 上使用 ImDisk 工具生成内存盘）防止客户端本地硬盘读写性能成为瓶颈。

先看看 RHEL6 Linux 系统下的 rsync 备份性能结果：

/dev/shm # rsync -hv 0.dat test@192.168.1.35::sync/
Password:
0.dat

sent 1.61G bytes  received 27 bytes  82.50M bytes/sec
total size is 1.61G  speedup is 1.00

/dev/shm # rsync -hv test@192.168.1.35::sync/0.dat .
Password:
0.dat

sent 59 bytes  received 1.61G bytes  91.93M bytes/sec
total size is 1.61G  speedup is 1.00

可以看到 Linux 系统下 rsync 写一个大概 1.6 GB 的文件可以达到 82.50 MB/s，读可以到 91.93 MB/s。

然后在 Win10 的 Bash 环境中同样使用自带 rsync 命令进行测试：

zzm@ZZM-VOLANS:~$ rsync -hv 1.dat 192.168.1.35::sync/
1.dat

sent 1.57G bytes  received 30 bytes  89.90M bytes/sec
total size is 1.57G  speedup is 1.00

zzm@ZZM-VOLANS:/mnt/h$ rsync -hv 192.168.1.35::sync/1.dat .
1.dat

sent 45 bytes  received 1.57G bytes  95.34M bytes/sec
total size is 1.57G  speedup is 1.00

看起来结果还是比较惊喜的，Win10 Bash 上的 rsync 命令可以基本跑满千兆网卡的带宽，备份性能甚至比 Linux 上的效果还好了那么一点点。这样不得不说我之前写的那篇文章里总结的 Windows 推荐使用 Cygwin 做 rsync 客户端的建议在 Bash on Ubuntu 推出之后就要过时咯。

总结

从 Win10 年度更新的简单试用和性能测试情况来看，Bash on Ubuntu 目前还算比较符合我的预期的，毕竟我最想要的直接在 Windows 上编译 Linux 二进制程序就更加方便了，看起来也不需要专门开虚拟机来进行编译工作中需要用到的 Linux 内核和应用程序了。当然目前 Bash on Ubuntu 仍然有不少问题和限制（毕竟还是 beta 阶段），还是希望微软能在后续更新中解决咯，祝大家玩的开心。