出于管理不同服务器以及自己几个 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 月玩得开心 ^_^。

mintty 的项目网址：

https://code.google.com/p/mintty/

这两天使用 mintty 的时候却突然发现配合 MSYS 怎么也无法正常启动了，而且没有任何报错信息，最后通过 MSYS 的 rxvt 终端运行才看到了报错提示：

[Administrator@msys ~]# mintty
m.AllocationBase 0x0, m.BaseAddress 0x68550000, m.RegionSize 0x4B0000, m.State 0x10000
C:\msys\bin\mintty.exe: *** Couldn't reserve space for cygwin's heap (0x68550000 <0x13C0000>) in child, Win32 error 0

在这个网址上看到了有人提出了使用 rebase 命令修改 MSYS DLL 文件首选基地址的解决方法：

http://dreamcloud.artark.ca/msys-not-start/

每个 DLL 文件都有一个首选的基地址，表示映射到使用的进程地址空间中的首选地址，一般默认为 0x10000000。实际情况下可执行程序一般会使用多个 DLL 文件，如果多个 DLL 文件都使用默认的首选基地址会造成系统自动做基地址重定位操作，这样可能导致进程地址空间中碎片的存在，并影响 DLL 的加载效率，因此有些 DLL 文件就直接自己指定了首选基地址。

如果需要查看某个 DLL 文件当前的基地址，可以使用 dumpbin.exe 命令行工具来查看，也可以使用 Dependency Walker 程序打开 mintty.exe 可执行文件，然后查看使用的 msys-1.0.dll 的基地址，例如我修改之前的效果如下图：

查看DLL基地址

从图中可以看出修改之前 msys-1.0.dll 文件的基地址（就是 Base 那一栏了）是 0x68000000。

按照上面链接提供的方法，首先需要退出 MSYS shell，并保证所有使用 MSYS DLL 的程序都停掉，先备份 msys-1.0.dll 文件，然后在 Cygwin 或者 cmd 里直接运行 rebase 命令修改 MSYS DLL 加载基地址为 0x76000000：

[Administrator@cygwin ~]# rebase -b 0x76000000 msys-1.0.dll

直接在 MSYS shell 里修改的话会由于 msys-1.0.dll 正在被使用而修改失败。修改成功之后重新运行 mintty.exe 程序，但还是有问题启动不了，报错信息相应也变了：

[Administrator@msys ~]# mintty
m.AllocationBase 0x763C0000, m.BaseAddress 0x76550000, m.RegionSize 0x23A000, m.State 0x1000
C:\msys\bin\mintty.exe: *** Couldn't reserve space for cygwin's heap (0x76550000 <0x1610000>) in child, Win32 error 0

看来这个修改过的基地址还是有问题的，估计还是和 mintty 程序有冲突的，我们再修改 DLL 基地址为 0x60100000 看看：

[Administrator@cygwin ~]# rebase -b 0x60100000 msys-1.0.dll

这下再运行 mintty 程序终于正常工作了，另外如果系统里没有 rebase 命令的话也可以使用 Visual Studio 2010 中自带的 editbin.exe 程序来修改 DLL 文件基地址的哦，玩的开心 ^_^。

之前因为一个项目需求，需要在 Windows 上使用 Bash 脚本运行 Windows 上的程序，因此想到在 Cygwin 的 Bash 里实现（好吧，这确实比较令人蛋疼）。运行 Cygwin 中的 bash.exe 调用脚本，并启动另一个 VBScript 脚本来对一个 Excel 文件进行修改处理（使用 Windows 的原因了）。

刚开始通过 cscript.exe 命令在 Windows 自带的命令提示符中运行 VBScript 还比较顺便，能顺利打开 Excel 文件并处理成功。但通过 Cygwin 的 Bash 脚本运行之后却老是在 VBScript 的打开 Excel 文件的地方提示找不到文件打开失败，顿时非常困惑。

Cygwin 的 Bash 脚本例子如下，test.sh 为 Bash 脚本程序，xxx.vbs 为处理 Excel 文件的 VBScript 脚本程序，运行 VBScript 脚本前需要先读取输入并传给 VBScript 脚本作为参数：

#!./bash
echo "Test script..."
read TESTVAL

# xxx do something xxx

read TESTLEN
echo "Require length: $TESTLEN"

cscript //Nologo xxx.vbs $TESTVAL

# xxx do something else xxx

read TESTEND
echo "...."

初步考虑是 Cygwin 开启的 shell 权限不足，为解决问题，便尝试了各种方法：

• 建立快捷方式设置以管理员方式运行，问题依旧；
• 把 Cygwin Bash shell 换为 MSYS 的，还是同样的报错；
• 通过 runas 命令以指定用户身份运行 cscript.exe VBScript 脚本，依旧。

但非常奇怪的是，我手工运行 Cygwin bash.exe 开启一个终端，然后在终端中运行 cscript 调用 VBScript 结果却又一切正常。

为此不得不又把目光转移到 Bash 脚本代码中，除了刚开始有两个 read 读取输入和 echo 输出操作外，并没有什么特殊的操作。实在找不到办法，就把 cscript 操作放在脚本最前面（使用固定参数，不通过读取输入的方式传入），再运行 test.sh 却惊奇的发现可以正常工作了。有点头绪了，由于运行 VBScript 必须从当前 Bash 脚本中传入参数，因此尝试着把第二个暂时不是特别必要的 read 和 echo 操作注释掉（第 7 和 第 8 行），也工作正常。

再经过反复测试发现 Cygwin 启动的 Bash 在运行了两次 read 操作之后再调用 VBScript 脚本就会出现权限不对的问题，只 read 一次或者完全不做 read 读取输入操作（cscript 命令放在最开始）都不会有问题。

现在也实在没明白两次 read 读取输入操作会导致什么系统环境不一样才使 VBScript 运行失败，Google 之后有朋友也遇到这种问题但没有正确的解答，可能这种改 read 方式并不彻底，但目前也算权宜之道了 ^_^。

rsync是一个开源免费的文件同步和备份工具，可用于本地备份，本地与远程服务器之间的备份，可以实现增量和差异备份，而且由于比较好的算法，在文件备份速度上也相对其它一些文件备份工具有明显的优势。

但 rsync 一直以来没有 Windows 下的原生客户端，都是基于 cygwin 环境实现，实际备份性能会受一些影响，近日看到 rsync 的 基于 MSYS 的 Win32 原生客户端已经被 port 出来，故简单做下性能对比测试。

测试环境：

rsync服务器为 RHEL5 Linux 64bit，8个SATA盘的RAID0做下层存储，采用单千兆网络和千兆交换机
rsync客户端为：RHEL5 Linux 64bit，Windows 2003 Enterprise 32bit

测试时 rsync 均通过匿名方式访问，不经过SSH做用户验证，由于考虑到测试的 rsync 客户端的系统盘速度有瓶颈，客户端文件读写都通过内存文件系统来实现（Linux 上使用 tmpfs，Windows 上使用 ImDisk 模拟内存盘）。

使用同样的客户端主板分别在 Linux 和 Windows 内存中产生 1.5GB 的测试文件，然后通过 rsync 客户端进行备份到服务器（写操作）和从服务器上恢复（读操作）的操作。

备份命令示例：
rsync -hv x.dat 192.168.1.125::rsync0/

测试软件列表：

• 标准 Linux rsync 客户端（RHEL 5 系统自带）
• cygwin rsync 客户端
• MSYS rsync 客户端
  http://sourceforge.net/projects/mingw/files/MSYS/Extension/rsync/
• RsyncWin32 客户端
  http://sourceforge.net/projects/rsyncwin32/

测试结果：
 

从测试结果看，由于 rsync 本身面向类 Linux 环境开发，在 Linux 系统中有着非常好的性能，cygwin rsync 与 Linux 相比有一定差距，但实际使用中还是比较稳定的，而 MSYS rsync 还处于测试阶段，虽然没有出现备份错误，但在千兆网络环境下性能非常差，RsyncWin32 则相对而言问题比较多，备份过程中甚至会出现备份错误。

综上看来，目前在 Windows 上使用 cygwin rsync 做备份客户端仍然算是比较好的解决方案，MSYS rsync 的问题可以啥时候有空再看看咯。