Welcome to Neilpang's Blog!
记录生活,分享知识,传播乐趣-
fstab,mtab,mount,fdisk 查看系统磁盘详情
fstab 文件想必大家都很熟悉，记录了计算机上硬盘分区的相关信息，启动 Linux 的时候，检查分区的 fsck 命令，和挂载分区的 mount 命令，都需要 fstab 中的信息，来正确的检查和挂载硬盘。
root@t1:/home# cat /etc/fstab
proc /proc proc defaults 0 0
none /dev/pts devpts rw,gid=5,mode=620 0 0
none /run/shm tmpfs defaults 0 0
除了 fstab 文件之外，还有一个 mtab 文件，和 fstab 文件一样在 /etc 文件下，位于 /etc/mtab。
mtab 文件记录的是，当前已挂载的分区信息。每当 mount 挂载分区、umount 卸载分区，都会动态更新 mtab，mtab 总是保持着当前系统中已挂载的分区信息，fdisk、df 这类程序，必须要读取 mtab 文件，才能获得当前系统中的分区挂载情况。 原文来自 blog.byneil.com
root@t1:/home# cat /etc/mtab
/dev/simfs / simfs rw,relatime,usrquota,grpquota 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /dev/pts devpts rw,nosuid,noexec,relatime,mode=600,ptmxmode=000 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0
none /run tmpfs rw,nosuid,noexec,relatime,size=419432k,mode=755 0 0
none /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
none /run/shm tmpfs rw,relatime 0 0
df 可以查看当前系统的已挂在的磁盘信息：
fdisk –l 查看系统所有已分区和未分区的磁盘， 并能划分磁盘分区。
mount –l 也能查看当前系统的挂载情况
原文来自 blog.byneil.com
-
联通宽带又在调皮了。给我分配内网ip
刚才偶然看了一下路由器， 不知什么时候起，联通开始分配内网ip了？
来自 blog.byneil.com
-
rsync 远程同步文件
rsync 有两种工作方式， 这里用的是“方式”这个词，而不是“模式”。注意区分。
第一种方式是 服务器--客户端方式。
在这种方式下， 服务端启动daemon 守护进程， 监听在端口 873， 并配置需要同步的模块。 然后客户端直接链接到873端口，通过认证，并同步。
其中，同步用的账号和密码都是rsync专用的，在rsync配置文件中独立配置。 于系统账号无关。
服务端运行rsync进程在daemon模式下， 客户端是普通的rsync进程。
这种模式下，客户端只能同步服务端事先配置的模块（目录）。 不能访问其他路径。
服务端配置方法参考：
第二种方式， 通过ssh链接。
这种方式下， 无需事先配置远程服务端。
本机 rsync 进程 直接通过 ssh 通道连接到远程， 并在远程ssh通道执行命令： rsync –******
本地rsync进程和远程rsync进程 通过自己的标准输入和标准输出 互相通信。 具体的说就是，本地进程监听ssh通道的远程回显当做输入， 把自己的的输出通过ssh通道发送给远程。 而远程的rsync进程就一样， 也会监听ssh通道的输入，当做自己的输入，然后把自己的输出写入到ssh通道。
于是， 远程rsync进程和本地rsync进程就通过这种方式同步文件。
这种情况，无需事先配置远程服务端， 只要你有ssh权限登录，就能同步。
同步的路径无限制。 当然只能访问你的ssh账号所能访问的目录。 如果你是root那就是无限制了。
这两种工作方式下，只是传输的通道不一样，第一种是直接走socket通道。 第二种是走的ssh通道。
安全性显而易见。
两种方式下，rsync都使用自有协议进行同步，所以可以携带的参数都是没有区别的。
具体实例：
rsync 的一般形式：
2: rsync -options SRC DEST当通过ssh链接时， 有时需要指定ssh端口， 请使用这个方式：
1: rsync -options -e "ssh -p 10000" SRC DEST
（注意，是否使用ssh通道，与上面这个参数没有必然联系。我这里指定了10000端口）
我们以从远程 向 本地拷贝为例，
这个时候， SRC 应该是远程地址.
其形式应该是：
如果远程是daemon模式：
MODE是远程daemon事先配置好的 模块名字。这里只能使用已经配好的模块名字，不能使用路径。
注意HOST于MODE之间有两个冒号。 这是rsync用于区分模式的唯一方法。
例子，拷贝远程模块到本地：
1: rsync -vzrtopg --progress --delete user1@192.168.168.52::WEB /tmp/把远程的 WEB模块，拷贝到本地的tmp目录。
或者是：
直接使用ssh模式：
1: USER@HOST:Folder这里，后面跟的直接是Folder的完整路径。 当然是USER所能访问的地方。
注意这里HOST和Folder之间用的是一个冒号， rsync由此判断使用ssh通道。而不是直接连接远端的873端口。
例子：
1: rsync -vzrtopg --progress --delete root@192.168.168.52:/home/wwwroot/ /tmp/这里是使用root用户登录远程服务器， 并把远程的 /home/wwwroot/ 目录同步到本地的 tmp 目录。注意与前一种的区别， 只有一个冒号。 这里会提示输入远程root的密码，如果已经配置了public key ssh 登录远程机器，就无需输入密码了。
常用rsync命令参数：
1: rsync -vzacu /home/wwwroot root@198.***.***.***:/home/ --exclude "wwwroot/index" -e "ssh -p 22"
这是一个通过ssh通道从本地推送到远程的例子。 把本地的/home/wwwroot 推送到远程的/home下面。
参数说明，
-z 表示传输过程压缩
-a 表示采用归档模式， 拷贝文件时，保留文件的属主，用户组，权限等等信息。
-c 表示校验文件checksum
-u 表示update，只传送更新的文件。rsync会比较文件的修改时间。只有较新的文件才会被同步。
参考：
Rsync命令参数详解 - 技术文档 - 系统管理 Linux时代 - 开源、自由、共享 - 中国最大的Linux技术社区
-
ssh 使用public key 免密码登录
第一步，生成自己公钥， 私钥
1: ssh-keygen -t rsa2:3: root@yjlml:~# ssh-keygen -t rsa4: Generating public/private rsa key pair.
5: Enter file in which to save the key (/root/.ssh/id_rsa):
6: Enter passphrase (empty for no passphrase):
7: Enter same passphrase again:8: Your identification has been saved in /root/.ssh/id_rsa.
9: Your public key has been saved in /root/.ssh/id_rsa.pub.
10: The key fingerprint is:
11: 3e:6e:d9:12:7c:f8:6f:18:f6:65:cb:6e:16:4f:83:43 root@yjlml12: The key's randomart image is:
13: +--[ RSA 2048]----+14: | |15: | |16: | |17: | E |18: | .S. . . |19: | .+ + o+..|20: | oB + +.=.|21: | .+.+ o = .|22: | ... o.+. |23: +-----------------+中间连续按几次回车， 使用默认文件名， 并不输入密码。
二， 把你的公钥，拷贝到远程机器的 “~/.ssh/authorized_keys” 文件中。
刚才生成的公钥在： ~/.ssh/id_rsa.pub， 里面是文本，直接复制出来，粘贴到远程的“~/.ssh/authorized_keys” 文件中即可。 如果没有这个文件，自己新建一个。
这个文件可以保存多个公钥，只需要连续放在里面就可以了。
拷贝的方法有很多。自己想办法。
拷贝完成之后，重启一下ssh服务。
service ssh restart
然后测试是否成功：
1: root@yjlml:~# ssh root@190.***.***.*** -p 22 ls这里故意指定了一个端口22， 其实可以省略的。如果你的ssh端口不是22可以这样指定。
这句话是在远程执行一个 命令 ls， 看能不能执行成功。
如果能看到ls的结果。那就是成功了。
三， 错误处理
如果访问不成功，请检查远程机器的 “/etc/ssh/sshd_config ”文件：
找到其中的这一段。
6: RSAAuthentication yes7: PubkeyAuthentication yes8: #AuthorizedKeysFile %h/.ssh/authorized_keys
注意，必须开启 公钥认证， 检查公钥文件。
改完之后，重启远程ssh服务： service ssh restart
-
翻译，NTLM和频道绑定哈希（EPA）
为了过NTLM 的EPA认证， 参考了这篇文章，现在翻译过来，备查。
如果你知道NTLM，并且需要过EPA， 那么这篇文章一定是你最想知道的。
原文地址：
NTLM and Channel Binding Hash (aka Extended Protection for Authentication) - Microsoft Open Spec
=======================
Extended Protection for Authnetication (EPA) was introduced in Windows 7/WS2008R2 to thwart reflection attacks. This blog describes the changes in the implementation of NTLM Authentication that are needed to successfully authenticate to servers that have EPA enabled. Windows 7/WS 2008R2 and Windows 8/ WS2012 have EPA enabled out of the box.
认证的扩展保护(EPA) 在Windows7/WS2008R2 中引进, 用来对抗反射攻击. 本文介绍了要通过服务器端EPA认证,NTLM实现上的必要的改变. Windows7/WS2008R2 和Windows8/WS2012默认开启了EPA.
You can read the details about EPA here http://technet.microsoft.com/en-us/security/advisory/973811
这里有EPA进一步的细节.
The concept in EPA is that authentication packets should be bound to the secure channel on which they are transmitted. This concept is not new and is known as channel binding (RFC 5056). RFC 5929 describes channel bindings for TLS that Winodws uses to bind the secure channel to authentication. Please note that EPA also uses Service Pricipal Name (SPN) but it is not used for TLS and we will not discuss it here.
EPA的概念是认证的数据包应该绑定到传输它的安全频道上. 这个概念并不是全新的, 它就是众所周知的频道绑定(RFC5056). RFC5929描述了描述了Tls的频道绑定, Windows用它绑定安全频道到认证. 请注意, EPA同样也使用了服务主体名称(SPN), 但是这没有被用于TLS, 我们在这不讨论它.
Let's take an example of HTTPS, a protocol that uses TLS. Once a secure channel is established and cipher change has happened, HTTP traffic starts flowing. In this example, we are only considering services that require authentication. NTLM or Kerberos will be used if you are using Windows authentication. You are most likely to use NTLM since the whole point of using HTTP and TLS is to allow clients to connect over internet (In Windows 8, Kerberos can be used on the internet but we will concentrate on NTLM here). In case of Windows client, these are the steps that are taken to incorporate channel binding in the authentication process after secure channel has been established:
我们看看HTTPS协议, 它使用了TLS. 一旦安全频道建立,并且密码交换完成, HTTP就开始传输. 在这个例子中, 我们只关心需要认证的服务. 如果你正在使用Wndows认证的话, NTLM或者Kerberos将会被应用.你很可能会使用NTLM, 因为在TLS上使用HTTP的全部原因就是允许客户端通过Internet连接. (在Windows8中, Kerberos也能引用于internet, 但是我们仍然集中在NTLM上.) 对于Windows客户端, 在安全频道建立之后, 认证过程中, 构成频道绑定的步骤如下:
1. The hashing algorithm for the signature in the certificate is identified, if present.
如果存在, 证书签名的哈希算法先被识别出来.
2. SSPI calculates a hash (almost always SHA256 hash, see below for details/exceptions) of the certificate, appends other data relevent to the type of channel bindings and returns it to the application.
SSPI 计算证书的哈希值(通常是SHA256, 后面会有细节和例外), 加上频道绑定类型的相关数据, 然后返回给应用程序.
4. SSPI calculates the MD5 hash of channel bindings and uses it in the calculation of NTLM version 2 response.
SSPI 计算频道绑定的MD5哈希值, 用于计算 NTLM version 2 的回复
5. When server recives authenticate message, it queries SSPI for channel bindings. SSPI does exactly the same thing as on the client side and returns the data to the service. The service includes it in the call to method Accept Security Context (ASC)
当服务器接收到认证消息之后, 它像SSPI查询频道绑定. SSPI 进行域客户端完全一样的操作, 并把数据返回给服务. 服务端在 接受安全上下文(ASC)的调用中包含这个数据.
6. In the process of verifying authenticate message, SSPI also takes into account the channel bindings. It calculates the MD5 hash of the channel bindings that were provided by the application (service) and compares it to the one sent by the client. If they match and rest of the authentication requirements are met, authentication is successful.
在校验的认证消息的过程中, SSPI同样要考虑频道绑定. 它会计算应用(服务)提供的频道绑定的MD5值, 并且和客户端发送过来的值进行对比. 如果匹配, 并且人权衡的其他条件满足, 则认证成功.
I'll now elaborate on each of the step listed above with a concrete example of RPC-over-HTTP traffic. The TLS network traffic is encrypted and I used Network Monitor expert Network Monitor Decryption Expert (NmDecrypt) to decrypt it. The decrypted network trace is attached to this blog.
下面使用一个具体的 RPC-over-HTTP 的传输来具体描述上面的每一步. Tls的网络传输都是加密的, 我使用了 Network Monitor expert Network Monitor Decryption Expert (NmDecrypt) 来解密. 解密的网络跟踪在帖子的附件中.
If you open the network trace in Network Monitor, you'll see that in frame 16 server sends a certificate to client, as below (copied and pasted from the trace):
打开 网络跟踪日志, 你会发现在第16帧, 服务端发送了一个证书给客户端, 如下:
......
After secure channel is established and cipher change has taken place, HTTP traffic starts flowing.
在安全频道建立之后,并且密码交换完成, HTTP传输就开始了.
In this example, HTTP is being used as a transport for RPC and RPC server requires authentication. For authentication, the client application first calculates the channel binding by using the following process(in Windows this is done by SSPI but that is not important in this discussion ). This process is based on RFC 5929.
在这个例子中, HTTP用来传输RPC, 并且RPC服务器要求认证. 对于认证, 客户端首先计算频道绑定, 过程如下(在Windows中, 由SSPI完成, 但这不重要): 这个过程基于RFC5929.
1. The channel binding type for this example is "tls-server-end-point" since a certificate is used in handshake (RFC5929).
频道绑定类型在本例中是 "tls-server-end-point", 因为在握手时使用了证书.
2. The client calculates a hash of the certificate. The hashing algorithm is SHA-256, unless all of the following conditions are met, in which case the signature algorithm in the certificate will be used.
客户端计算证书的哈希值. 哈希算法是SHA256, 除非下面的条件都满足, 此时将会使用证书的签名算法.
A certificate signature algorithm exist
证书签名算法存在
The algorithm is only implemented in CNG (ALG_ID is CALG_OID_INFO_CNG_ONLY)
(证书签名)算法只在CNG中实现(ALG_ID 为 CALG_OID_INFO_CNG_ONLY).
The algorithm has a corresponding CNG algorithm identifier string (pwszCNGAlgid)
(证书签名)算法有相应的CNG算法标示字符串(pwszCNGAlgid)
The algorithm is not SHA1
算法不是SHA1
The algorithm is not MD5
算法不是MD5
3. The SHA-256 hash of the above certificate is: ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95
上面证书的SHA-256哈希值是: ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95
4. The Channel binding unique prefix (RFC5929) "tls-server-end-point" is prefixed to the hash above (with a colon), resulting in
74 6c 73 2d 73 65 72 76 65 72 2d 65 6e 64 2d 70 6f 69 6e 74 3a ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95
频道绑定前缀"tls-server-end-point"被附加到这个hash值得前面(冒号分隔):
74 6c 73 2d 73 65 72 76 65 72 2d 65 6e 64 2d 70 6f 69 6e 74 3a ea 05 fe fe cc 6b 0b d5 71 db bc 5b aa 3e d4 53 86 d0 44 68 35 f7 b7 4c 85 62 1b 99 83 47 5f 95
5. The above value is inserted as the value of application_data field of gss_channel_bindings_struct structure, as pointed out by MS-NLMP section 2.2.2.1
上面这个值插入到 gss_channel_bindings_struct 结构的 application_data 字段 . 这个字段在 MS-NLMP section 2.2.2.1 描述.
6. Windows always sets the other fields of gss_channel_bindings_struct as zeros (SEC_CHANNEL_BINDINGS
structure). The resulting gss_channel_bindings_struct is as follows (little endian format):
Windows 总是将 gss_channel_bindings_struct 机构的其他字段设为 0. gss_channel_bindings_struct 结构的结果如下(小端格式):
00 00 00 00 //initiator_addtype
00 00 00 00 //initiator_address length
00 00 00 00 //initiator_address pointer
00 00 00 00 //acceptor_addrtype
00 00 00 00 //acceptor_address length
00 00 00 00 //acceptor_address pointer
35 00 00 00 //application_data length (53 bytes)
20 00 00 00 //application_data pointer (32 bytes from start of this structure)
74 6c 73 2d //application data, as calculated above
73 65 72 76
65 72 2d 65
6e 64 2d 70
6f 69 6e 74
3a ea 05 fe
fe cc 6b 0b
d5 71 db bc
5b aa 3e d4
53 86 d0 44
68 35 f7 b7
4c 85 62 1b
99 83 47 5f
95
After calculating channel binding, the client application starts authentication and include channel binding as part of authentication. In case of NTLM, the gss_channel_bindings_struct is called ClientChannelBindingUnhashed (MS-NLMP section 3.1.1.2). As explained in MS-NLMP section 3.1.5.1.2, the client adds an AV_PAIR structure and set the AvId field to MsvAvChannelBindings and the Value field to MD5(ClientChannelBindingsUnhashed). The MD5 hash of the above gss_channel_bindings_struct turns out to be:
频道绑定完成之后, 客户端开始认证, 将频道绑定作为认证的一部分包含进来. 对于NTLM, gss_channel_bindings_struct 结构 被叫做: ClientChannelBindingUnhashed (MS-NLMP section 3.1.1.2). 正如 MS-NLMP section 3.1.5.1.2, 中所介绍的, 客户端添加一个AV_PAIR 结构, AvId字段设为 MsvAvChannelBindings, 而Value字段设为 MD5(ClientChannelBindingsUnhashed). 上面的gss_channel_bindings_struct 结构的MD5值如下:
65 86 E9 9D 81 C2 FC 98 4E 47 17 2F D4 DD 03 10This value is part of the AUTHENTICATE_MESSAGE in frame 27 in the network trace attached (in the network trace it is shown in Base64 encoding as 45 41 42 6C 68 75 6D 64 67 63 4C 38 6D 45 35 48 46 79 2F 55 33 51 4D 51 with AvLen) .
这个值作为AUTHENTICATE_MESSAGE 认证消息的一部分, 在附件的第27帧(附件中显示为Base64的编码值: 45 41 42 6C 68 75 6D 64 67 63 4C 38 6D 45 35 48 46 79 2F 55 33 51 4D 51 包含 AvLen ).
When server receives the AUTHENTICATE_MESSAGE, in addition to the regular authentication processing, it also verifies the channel binding hash by calculating it the same way the client did. If the channel binding hash does not match, the authentication will not be successful. The subsequent behavior is server dependent. In this example (IIS), the server will stop communication on unsuccessful authentication.
当服务端收到 AUTHENTICATE_MESSAGE 认证消息之后, 除了做常规的认证处理之外, 它还校验频道绑定数据, 与客户端同样计算一遍. 如果频道绑定数据不匹配, 认证就失败. 之后的行为就和服务器相关. 在这个例子中(IIS), 服务器会停止通信.
Please note that two step hashing is being employed here. First the application creates a hash of the certificate which becomes a part of gss_channel_bindings_struct structure. This structure is MD5 hashed again to be included in AUTHENTICATE_MESSAGE.
请注意, 这里应用了2步哈希. 首先应用程序计算证书的哈希值, 使其成为 gss_channel_bindings_struct结构的一部分. 这个结构又被计算MD5 哈希值, 用来包含在 AUTHENTICATE_MESSAGE中.
There are configurations on both Windows client and server side to disable the EPA. For the server side, please consult the server specific documentation. As for the server in this example, IIS, please consult http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication/extendedprotection.
在Windows客户端和服务端都有配置来禁用EPA. 对于服务端, 请参考服务端规范. 对于本例中使用的IIS, 请参考:
http://www.iis.net/configreference/system.webserver/security/authentication/windowsauthentication/extendedprotection
On the client side, there is a registry setting that is described in KB976918 (http://support.microsoft.com/kb/976918) that can be used to configure EPA.
对于客户端, KB976918 描述了一个注册表设置(http://support.microsoft.com/kb/976918) 能用来配置EPA.
==============================
本文不是完全对照翻译，但是力求主题意思清楚。 请参考原文阅读：
NTLM and Channel Binding Hash (aka Extended Protection for Authentication) - Microsoft Open Spec
欢迎大家交流讨论。
-
Ubuntu 修改主机名/机器名
修改 /etc/hostname 和 /etc/hosts 文件对应的机器名
