出于管理不同服务器以及自己几个 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 阶段），还是希望微软能在后续更新中解决咯，祝大家玩的开心。

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 方式并不彻底，但目前也算权宜之道了 ^_^。

Windows Server 2012 系统中更新支持的 SMB 3.0 网络共享协议相对于原来的 SMB 1.0 有诸多改进，例如：RDMA 支持、Multichannel 多通道支持等等，详情请参考我之前写过的文章介绍如何在 Windows Server 2012 中使用 SMB 3.0 over RDMA：

https://zohead.com/archives/smb3-over-rdma-performance/

这里我主要关注 SMB 3.0 Multichannel 的实际效果，Multichannel 可以实现 SMB 客户端和服务器之间同时发起多个 SMB 连接（对于 SMB 1.0 和 2.0 是很大进步之一），通过在多网卡环境下使用 SMB 3.0 Multichannel 可以达到提高系统吞吐量、支持错误容忍、多通道自动配置等效果，从上面的文章中再来回顾下 SMB 3.0 的 Multichannel（多通道）需要的条件：

• SMB 服务器和客户端计算机必须都为 Windows Server 8 或者 2012；
• 必须都有多个网卡，网卡类型和速度需要一致，或者其中一个或多个网卡支持 RSS 或者 NIC Teaming（网卡绑定）或者 RDMA。

有一点需要说明的是 samba 新推出的 4.0 正式版本虽然提供了 SMB 3.0 协议的支持，但并不支持 Multichannel 多通道、RDMA 这些高级功能的，因此此测试暂时还只能在 Windows Server 2012 系统中做了。

测试环境

服务器：

Intel S5500BC 服务器主板；

Intel Xeon E5506 CPU * 1；

Kingston DDR3 1066 4G 服务器内存 * 1；

Intel EXPI9402PTBLK 双千兆网卡（PCI-E x 8 插槽）；

LSI MegaRAID 84016E RAID卡（PCI-E x 8 插槽）；

WD WD10EVDS 1TB SATA 监控硬盘 * 16；

Windows Server 8 Beta Datacenter Build 8250 64位中文版；

客户端：

TYAN S7002 服务器主板；

Intel Xeon E5506 CPU * 1；

Kingston DDR3 1066 2G 服务器内存 * 1；

主板内置双千兆网卡；

Windows Server 8 Beta Datacenter Build 8250 64位中文版；

其它环境：

TP-LINK 24 口千兆交换机；

测试软件：

IBM Tivoli SANergy（测试大块文件连续读写）；

测试步骤及结果

SMB Multichannel 在 Windows Server 2012 系统中默认就是启用的，你可以分别在服务器和客户端中的 PowerShell 中运行 Get-SmbServerConfiguration 和 Get-SmbClientConfiguration 命令查看 Multichannel 是否已经启用。

然后可以在 PowerShell 中分别运行 Get-SmbServerNetworkInterface 和 Get-SmbClientNetworkInterface 命令查看是否满足多通道的条件。以我的实际测试环境为例，先看看服务器上的配置：

从图中可以看到服务器中是两个千兆网卡，两个网卡的 IP 地址在同一网段，Interface Index 为网卡的序号（后面会用到），另外会显示 RSS 和 RDMA 都是不支持的，此时表示可以使用多通道。需要说明的是如果两个网卡都是千兆的，但是一个支持 RSS，另一个不支持 RSS，SMB 3.0 Multichannel 在类似这种情况下也是不能使用的。

再来看看客户端上的网卡情况：

客户端的网卡多一些，但我们只需看网络通了的网卡（Interface 12 和 13），也是千兆网卡，两个网卡的 IP 地址也在同一网段（图中显示的是 IPv6 地址，实际也都在 192.168.1.0 网段），但两个网卡都支持 RSS，不支持 RDMA，这样多通道也是可以用的。

在服务器上建立磁盘阵列（我是建的 RAID5 哦），建立共享目录，然后在客户端上通过映射网络驱动器访问共享目录即可，由于要使用多通道，因此最好直接使用 “\\服务器主机名\共享名称” 这种形式（不要直接指定服务器上的某个 IP 地址）。

客户端中连接上共享目录之后，就可以在客户端的 PowerShell 中运行 Get-SmbMultichannelConnection 命令查看 SMB 连接是否使用了多通道：

从上图可以看到详细的 SMB 连接信息，也可以明显的得出客户端到服务器的连接已经启用了多通道（不同的客户端 IP 地址对应不同的服务端 IP 地址，从客户端和服务端的 Interface Index 网卡序号也可以看出）。另外虽然客户端网卡是支持 RSS 的，但由于服务端并不支持，因此 SMB 连接仍然未启用 RSS，当然 RDMA 就更没有启用了。

下面就可以用测试软件进行读写测试了，测试过程中可以分别看客户端和服务器上的网卡占用情况，就可以看出 SMB 3.0 多通道已经发挥作用（两个网卡都有读写产生的流量的）：

接着就可以测试容错功能是否有用了，在读写测试过程中，拔掉客户端或服务器的一根网线，可以看到对测试过程没有影响，读写可以继续进行。由本测试可以看到，Windows Server 2012 中的 SMB 3.0 多通道基本可以实现我们需要的类似负载平衡的目的，而且多通道在一般情况下完全不需要用户进行配置，Windows 会自动选择类型和速度完全一致的网卡自动进行多通道匹配。

参考链接：

http://blogs.technet.com/b/josebda/archive/2012/06/28/the-basics-of-smb-multichannel-a-feature-of-windows-server-2012-and-smb-3-0.aspx