当初犹豫是买16还是32
后来买了32
很庆幸当初没买16

@Shared 那就等高人回答吧 问题我先记下了 等假期到了这么玩试试

vsftpd支持virtual users 可以看看

以前看过vsftpd的源代码，没用过PAM.

刚找了下：
你那个错误在prelog.c:282行，对应函数是handle_pass_command，这个函数是处理PASS（FTP协议）时执行的，用来验证密码。走到这里，说明密码验证失败。

你可以debug编译（更改Makefile的link选项，我记得它是在link时指定去掉调试信息的，不去掉加-g也没用），然后单步追踪。看看问题在哪里。

VSFTPD为了安全，在默认的twoprocess下用sockpair进行进程间通信，只有那个保留root权限的进程才执行验证功能，另外一个drop权限后进行服务。这样的话调试比较麻烦，你可以在配置文件中设置为oneprocess.

最后PAM验证的部分貌似在sysdeputil.c:vsf_sysdep_check_auth中。根据这里的条件编译，请先确保你执行的版本编译选项没问题（我不知道怎么看，apt-cache show貌似没有，编译选项应该没保存在程序里），这里的PAM_RHOST/PAM_TTY/PAM_USER我没接触过，不知道是什么东东。

@standin000 AES是块加密，自行搜索块加密。每次加密输入是128位，对应128位输出。假如你要加密00001111（二进制串），你不填充到128位怎么加密？我之前实现用的是pkcs7. 其它还有很多填充标准。题外话，MD5算法也要用填充，用的是位填充，貌似必须补齐512位，记不清了。

为了防止相同块加密后的相同输出，通常会用到初始化向量和块加密工作模式。你潜意识里根本没有这些概念，以为加密只有这些就行了是不对的。

里边细节问题很多。想知道的话自己搜吧。
EOF

@standin000 这个密钥长度256位，属于正常长度，不是“太长”，但对AES来说已经是（我理解中能接触到的）最强的加密强度了。

AES算法的原型是Rijndael算法（相当于我要制定一个加密标准A，然后有a、b、c等各路算法投稿，最后算法a成为了加密标准A），它支持的相关参数选项要比AES多。

再多说一点吧：例如AES加密，每次加密的输入必须是128位，如果不足128位（通常是最后一组数据），需要用到填充算法，这个可以搜索维基百科中密码学下的Padding词条。你能保证原文（明文）长度一定是16字节的整数倍吗？

因此，你这个问题真的是无解的，不用想了。当然，假设问题成立，各个组合试一试总会有正确答案。即便如此，你知道了加密算法，比如是AES，你照样需要花费非常多的时间去暴力破解（前提是它加密用到了CBC、IV Padding之类的东东，是真正的加密）。

（其它对称加密算法不清楚，不知道哪些支持密钥长度是256位的）

实现过DES和AES.

DES真实密钥真有56位，不说了。

AES密钥长度128、192、256位，换算成字节分别是16、24、32个，如果一个字符算一个字节，分别是16、24、32个字符。通常你的密码连16都达不到。这时，要么把你的密码直接当成密钥用来加密，不够补零，要么就使用key stretching（自行查阅维基百科）。

我理解的正常情况下，密文不可能全部是可打印的ASCII字符。所以这里的密文很可能是转换过的（很可能有多次）。

通常对称加密的输出是“纯密文”，不包括加密参数（比如算法、密钥长度）的任何信息。如果你要做一个加密软件，那么就需要设计一个协议，并把它作为加密后文件的头（或其它）部分。协议里可能记录采用的加密算法、密钥长度、块加密模式、初始化向量（IV）等解密时必须的信息。

综上，无解。

@undozen

竟然因为这个回答太短被扣分 多说不都是废话么
好吧，我再回答一下：
上边的脚本执行过后，再执行
xmodmap -e "add control = Escape" 就达到你想要的效果了

当然，如果决定这么干了就把-e后的命令写入配置文件capslock和esc交换后

keyremap4macbook里有个timeout的选项，这个暂时不知道怎么在X中实现