20Centos5.0RSH配置问题.docx

20 Centos5.0的RSH配置问题 Root用户： 修改/etc/xinetd.d/rsh文件 Disable = yes 改成 disable = no 重启xinetd /etc/init.d/xinetd restart 在root用户的家目录/root中新建文件.rhosts（注意文件名前面有点，会成为隐藏文件） 加入客户端ip地址 修改/etc/securetty文件 在最后添加rsh 在客户端敲入命令/usr/bin/rsh 服务端ip ls 要看的文件的路径 非root用户： 同上 同上 在/etc中新建文件host.equiv 加入客户端ip和非root用户的用户名 同上5 注1：如果不想使用ip而想使用主机名，除了要把上面的ip换成主机名，还要在/etc/hosts中添加客户端ip与客户端主机名、别名，否则服务端是不会认识客户端的 注2：关于防火墙的问题，服务端可开启防火墙，在其他端口中添加端口514，协议tcp即可。而客户端，则由于rsh协议问题目前还无法解决，至少我没发现（关于这个问题可以参考 HYPERLINK /thread-3717-1-1.html /thread-3717-1-1.html rsh的网络通信细节 协议分析只是一种技术手段，最终不可能为了分析而分析。在这里逛了个把月，看了些贴子，感觉有一定比例的兄弟颠倒了因果。你没有需求，分析不分析、会不会分析的其实都无所谓。需求决定行动。其次，分析并不对应着抓包，抓包只是其中一个步骤，如果有文档有代码，不看白不看，能省点事就省点事。遇到需求，先用脑子分析分析，去找找去搜搜，然后再上抓包工具。那种一上来就什么过滤也没有、愣抓的事，老干就得不到进步。因为我想表达的意思是需求决定行动，先用脑子后用工具，所以这次不写那种细化到图示的操作指南，而是提供一个简单的记录，以说明通过协议分析我们得到了什么结论，学到了什么东西。其原始背景是在实现自己的rsh客户端程序时，发现从某台主机无法访问rsh服务，而rcp、rlogin成功，同时从另一台主机可以访问rsh服务。排除应用层配置错误的可能后，只好抓包了。结果抓了包才发现这个协议如此简单以致没有太多可供猜测的细节，被迫去Google，去man，去动态跟踪。--------------------------------------------------------------------------☆ rsh的网络通信细节由tt调试rsh服务、查看相关源码，并解释了为什么rshd会检查源端口。scz负责前期协议分析、后期测试代码编写。rsh服务侦听514/TCP口，而514/UDP对应syslog服务，与echo、chargen、daytime等服务不同，这次514/TCP、514/UDP不属于同一服务。下面的讨论基于已经了解rsh应用这个假设，不熟悉了可以查看rsh、rshd、rhosts、hosts.equiv手册页。rsh服务是否有RFC对应呢，反正我是没有Google出来，在几本bible上也未找到更多细节。在*nix上man rshd可以看到一些协议细节。如果有相关源码，最好看源码，man手册大多未能同步更新。client建立到server的514/TCP的连接。服务端会先检查TCP连接的源端口是否位于[512,1023]区间，否则服务端进程终止。*nix最早要求范围是[1,1023]，后来为消除一些安全隐患([1])，改成[512,1023]。但这是实现相关的，并且各个系统的man手册可能与其当前实现不同步，某些版本Solaris的man手册就有问题，应实测。为什么rshd有这个限制？假设B机上的root信任A机上的scz，并未信任A机上的tt，同时rshd对源端口没有限制。tt登录A机，自己写了一个程序向B机的514/TCP发送\0scz\0root\0id\0，尽管此时源端口必将大于等于1024，命令仍将成功地远程执行。反之rshd对源端口有限制，则tt必须设法使自己所写程序以root身份执行，才有可能指定小于1024的源端口。如果tt就是root，本就无所谓安全隐患。如果tt不是root，就阻止了tt伪装成scz。一般rsh、rcp、rlogin被设置成setuid-to-root，tt要想访问远端rshd，只能用系统自带的rsh、rcp、rlogin，但这三个程序会如实指定client_user字段，不存在伪造的可能。*nix历史上多是大型主机带多个哑终端，做这样的安全防范可以理解。假设client位于NAT后面，访问server时源端口很可能已经大于等于1024，由于对源端