3月下旬去了趟美国, 顺便买了两个Yubikey Neo回来, 这两天开始折腾了一下, 到能够使用的程度, 折腾过程中遇到不少坑, 本文以不求甚解的态度把这些坑都一一记录下来, 希望方便自己和其他想要折腾的同学.
其实第一个比较核心的问题是为什么要买以及怎么买.
简单说下Yubikey和yubico公司, Yubikey是一个电子令牌的系列, 这个系列特点的是便携并且价格低廉. 所谓电子令牌, 我的理解就是实现了某些加密算法或者认证协议的芯片, 通过外部接口(一般是USB接口)来提供加密或认证服务. 电子令牌的好处是将密钥和认证信息保存在便于携带的令牌上, 降低了在存储和传输过程中, 密钥或者认证信息被盗的风险.
我买Yubikey的主要原因是看中了它的OpenPGP Card的功能, 这样我就可以把PGP的私钥以及加密/签名的功能都放在电子令牌上, 这样就不同担心密钥被盗或者被误删了.
Yubikey系列目前有五个产品, 其中我买的是Yubikey NEO, 对于其他版本的限制和功能我也不是特别清楚, 有兴趣的同学可以自行研究下. Yubikey NEO在亚马逊和万能的淘宝上也能够买到, 但是买的事情要看清楚固件版本, 有些固件版本是不支持U2F的, 而Yubikey又因为安全性的考虑不支持固件升级.
所有的折腾过程都在ArchLinux下进行, 如果你使用的是其他Linux发行版, 我想过程应该大同小异. 而如果你希望能在Mac或Windows上使用Yubikey NEO, 坑的数量可能更多或者更少, 但是还是可以从本文获得一些借鉴.
需要说明的是, 这并不是一篇Yubikey NEO使用方法的教程(因为教程写起来太麻烦了, 并且有很多好心人已经写过). 你可以在使用教程之前, 阅读下本文, 对Yubikey NEO的功能有个大致的印象, 避免发生悲剧, 或者像我一样, 折腾了两天才搞定.
其实Yubikey是不需要的驱动的, 因为如果要做OTP或这U2F的话, Yubikey本身会作为一个HID设备, 就是一个USB输入设备, 而在Linux内核中, USB HID的设备是已经写好的了, 这就是为什么你把鼠标和键盘插上之后, 就可以直接工作的原因. 而如果是作为OpenPGP Card使用的话, Yubikey Neo已经遵照相应的协议提供了供gpg使用的接口, 因此也不需要安装驱动.
但是出于两个其他的原因, 我们需要安装一些工具软件. 原因之一是我们需要对Yubikey进行一些配置, 包括工作模式等; 原因之二是为了能够让终端用户访问Yubikey设备.
上面所说的两个目的都可以通过安装yubikey-personalization来实现, 因为yubikey-personalization已经自带了 一个udev的rule, 能够给Yubikey设备配置正确的环境变量, 从而保证能够被终端用户使用.
虽然AUR上有yubikey-personalization的包, 叫做ykpers, 但是我并不推荐安装它, 因为AUR上的ykpers的版本有些老, 不能支持新固件版本的 Yubikey了. 可以在yubikey-personalization的Compatibility页看到每个版本对应的支持的固件版本.
如果你跟我一样使用的是固件版本为3.3的yubikey, 那么你可以用在archlinuxcn源里已经打包好的ykpers, 也就是我正在使用的, 接下来本文会假设你使用的是固件版本3.3的yubikey并且使用archlinuxcn源里的ykpers.
在安装好ykpers之后, 首先你需要给Yubikey设置工作模式, 讲Yubikey插入电脑之后, 运行
ykinfo -v
可以参看是否能够识别当前插入的Yubikey, 能够识别的话就是可以进行后续的操作了. 通过运行
ykpersonalize -m <mode>
可以设置Yubikey的工作模式, 具体每个数字代表怎么的工作模式可以通过man ykpersonalize来查看. 但这里有一个可能的坑是, 先不要选择一个不带OTP功能的模式, 因为如果如果选择这样的模式, 比如说85, 那么ykpers可能就没办法识别出Yubikey来, 而造成不能把Yubikey设置为其他模式, 万一手滑设置成了这样的mode, 那么也不用慌张, 可以通过安装另一个管理软件ykneomgr来重新设置, 不过ykneomgr的依赖很多, 也会用到智能卡方便的daemon, 配置起来极其繁琐, 因而总的原则是不推荐..
将mode设置为85还有另一个潜在的问题, 那就是ykpers自带的udev rules里没有针对85 mode的设置, 因此会导致插上Yubikey之后, gpg没办法访问. 所以如果希望在85 mode下继续使用Yubikey, 就必须修改udev rules, 在ATTRS{idProduct}的取值范围中, 加入0115
不过, 话说回来, 我为什么要吃饱了没事做把模式设为85呢, 我相信你仔细看mode就会发现85的mode下禁用了OTP, 而我确实并不需要OTP功能, 如果你希望使用OTP功能, 那么大可不像我这么麻烦.
折腾了一大圈, 好不容易把Yubikey识别出来, 并且设置了期望的工作模式, 那么就下一步就应该是真正开始使用了. 首先正如大多数教程里面说的那样, 我们应该先运行gpg --card-status来检查gpg是否能够访问Yubikey, 如果不能, 可以重启gpg-agent重试.
一个Yubikey Neo中只能存放三个2048的PGP私钥, 而且为每个私钥分配了不同的功能, 分别是签名/解密/认证. 那么接下来你就可以欢快地按照任何一个教程所述来将密钥“存放”在Yubikey上了, 你可以选择直接在Yubikey上生成, 或是把已经生成好的key移动到Yubikey上. 但无论怎样, 当你把私钥放到Yubikey上时, 你本地密钥环中的私钥就不复存在了, 所以如果你希望能够backup私钥, 那么合理的做法是先生成私钥, 然后再将私钥到处, 最后再把私钥移动到Yubikey上.
到此基本上大功告成了, 等等你说gpg不能生成认证密钥(Authentication key)? 其实我个人也遇到这个问题, 而且作为一个gpg的老玩家, 我记得多年之前, gpg在生成密钥的时候还是可以选择密钥类型是否为A类型, 也就是Authentication key的. 但是我后来使用gpg 2.1的时候无论如何也没办法生成认证subkey, 直到后来, 我发现真相是gpg 2.1把Authentication key作为隐藏boss 而隐藏了起来, 需要在gpg命令行加入–expert选项, 进入“专家模式”才能设置密钥类型为Authentication, 比如:
gpg --expert --edit-key
那么认证密钥究竟有什么用呢? 我也说不清楚, 我个人是把它当作ssh的私钥来用的, 这样我正好可以把ssh私钥的拷贝也从电脑上删除了. 至于怎么用Yubikey上的私钥来作为ssh的私钥, 其实很简单, 因为gpg-agent本身也可以做为ssh-agent, 并且只需要两步就能完成: 1. 开启gpg-agent的–enable-ssh-support选项 2. 把私钥的keygrip放到.gnupg/sshcontrol文件里
(keygrip的解释:That is a protocol neutral way to identify a public key. It is a hash over the actual public key parameters. 可以通过命令gpg -k --with-keygrip得到)
2014年基本上在失落和倒霉中度过, 所幸完成了人生两件大事, 一是毕业, 二是工作, 也算是安定下来了吧. 最近总是在想以往的得失, 想自己浪费的光阴和失去的机会, 这感觉并不好受. 总结起来, 自己的懒散和漫无目的大概是影响最大的因素, 比如想写blog, 可很多时候只是写了两笔就停下了, 不知道去干嘛了. 学东西也都是东学一点, 西学一点, 没有什么长处. 所以我想试试看定个新年计划, 来看看自己会不会走出失落的怪圈.
经验告诉我, 我肯定会想到很多计划, 结果最后一个也完成不了, 所以我决定只定三个今年能够完成的就好. 以免注意力再分散…
就这些了.. 再多我估计我又要坑了. 等到来年看看完成度有多少吧.
]]>曾经当我考虑写个人Blog的时候,我用的是ruhoh,还写了一篇博文来说明为什么用ruhoh. 本来第一考虑使用Jekyll来写,因为概念上比较简单,而且用的人多,开发者的热情和社区的人数都有保证. 但是当时GitHub Pages还不支持Jekyll,只支持纯html. 这样Blog的源码和输出就得放到两个repo或者branch上保存,感觉好蛋疼.
但是后来,GitHub Pages开始支持Jekyll了,而ruhoh则升级到了2.0,我卡在了ruhoh升级的过程中,之后就不了了之了.
说实话,写下上面的话已经是快一年之前的事情,当时正好搞定小论文,想着写写blog充实下自己,结果没有坚持下来. 一年过去了,也不能说是发生了很多事情吧,但是每每想到自己还有一个单薄的未完工的个人主页,就觉得很懊恼, 懊恼很多之前没有坚持下来的事情,懊恼自己的懒惰.今天重新把这篇补完,其实是因为很有趣的原因: 我最近开始坚持github上每天都有commit,然而今天实在没有什么代码来写了,就想到来更新博客凑数… 不过,刚刚好今天是我的生日,就让这篇文章作为我新的blog的第一篇文章吧,算作是送给自己的生日礼物吧.
刚刚好最近给自己的主页想到了一个很好的名字,“朝闻道”,这大概就是我的人生追求吧.
]]>这是我的第一篇 ruhoh 框架下的blog, ruhoh是一个Static Blog Generator, 和Pelican与Octopress类似. 静态blog有着诸多好处, 不过我在这里不准备论述这些 :)
我是从刚入大学的时候开始写blog的, 首先用的是一些空间和门户网站一类的东西作为blog, 只是写写心情什么的,很难写出有深度的东西, 后来坚持了不到两年左右的vimwiki, 也是类似于静态blog的方法, 不过当时hosting是个大问题, 虚拟主机和域名都很麻烦, 而且经常容易出问题, 所以就只把wiki的源码保留在和GitHub上, 可能过些日子我就会wiki中的文章迁徙过来, 然后删掉那个repo把.
后来又热心折腾起blog来是因为GitHub Pages的兴起, 也鼓捣了一阵, GitHub Pages确实很方便, 提供了hosting和域名的服务(虽然是个*.github.com,不过就将就吧), 同时还有版本管理的功能, 依托Git强大的版本管理功能, 你可以记录你的pages发展的点点滴滴, GitHub也从此时起成为“程序员的facebook”.
不过, 就我折腾下来的感觉来看, 我并不是很喜欢GitHub Pages, 主要一点是冗余的问题. 因为如果你想使用GitHub Pages的服务, 你需要在GitHub上建立一个repo, 然后将你的网站内容push到这个repo的master分支, 每次当你更新这个分支的时候, Github Pages就随之更新. 这种hosting方式带来一个问题, 那就是你实际上在为输出做版本控制, 而如果你的这些输出的源文件不是html(或者是GitHub Pages支持的模板), 那么你还需要对源文件进行版本控制, 这一点让我觉得很麻烦. 当然如果你并不在意GitHub Pages上的那些历史信息, 每次都是git push origin +master, 那么这并不会成为你的困扰, 只是我觉得白白增加了一个repo的维护工作(也有用工具去做这个维护工作的, 比如说Octopresss, 但是解决方案并不完美), 我希望只去跟踪我的源文件. 更重要的是, 我觉得好的blog系统应该能够保留blog中内容的属性和分类, 能够从同一份内容中生成不同的表现(就算目前不能, 也应该为今后留下可能性).
所以我更喜欢只需要管理源文件一个repo的静态blog解决方案, 直到我发现了ruhoh, 在这里就不详细介绍ruhoh的特点了, 留到今后详细说明, 只是简单说一下ruhoh的机制, 你需要在GitHub上建立你自己blog的ruhoh, 然后通过web hook关联到http://post.ruhoh.com, 就能在每次push之后, 自动在ruhoh.com生成自己的页面, 当然, 你也可以不依赖于ruhoh.com, 自己将compile之后的网站内容host在任意主机上, 包括Github Pages.
至此, 我的只需要管理一份repo的静态blog方案找到了, 至于它与其他方案的优缺点和是否我这样的选择是正确的, 还要交给时间来考验.
]]>