RSH的网络通信细节

简介:

rsh 服务侦听 514/TCP 口, client 建立到 server  514/TCP 的连接。服务端会先检查 TCP 连接的源端口是否位于[512,1023] 区间,否则服务端进程终止。 *nix 最早要求范围是 [1,1023] ,后来为消除一些安全隐患,改成 [512,1023] 。但这是实现相关的,并且各个 系统  man 手册可能与其当前实现不同步,某些版本 Solaris  man 手册就有问题,应实测。

为什么 rshd 有这个限制?一般 rsh  rcp  rlogin  设置  setuid-to-root  client 要想访问远端 rshd ,只能用系统自带的 rsh  rcp  rlogin ,但这三个程序会如实指定 client_user 字段,不存在伪造的可能。只有 root 用户才能使用 [1,1023] 的端口。

那么 rshd 如何检查端口? client  server 发送如下请求数据 :

[port]\0<client_user>\0<server_user>\0<command>\0

Port ---- ANSI 字符串形式的端口号,不是短整型形式的端口号。

client_user ---- 客户端当前用户名

server_user ---- 试图远程使用的服务端用户名

command ----  试图远程使用的服务端命令

port 本身是可选项。如果指定了 port ,服务端会建立到客户端这个端口 (port)  TCP 连接, rshd 会将 stderr 重定向到这条连接上。 *nix 要求 port  [1,1023] 上,并且成功建立连接,否则服务端进程终止。但这是实现相关的, Solaris  Linux 自带rsh 命令,抓包表明它们都提供 port 字段,并且没有命令行开关改变这个行为。

server  client 发送如下响应数据 :

<ret><data>

ret 等于 0x00 表示成功, data 对应执行结果,一般是 \n 分隔、结尾的文本。

ret 等于 0x01 表示失败, data 对应错误信息,一般也是 \n 分隔、结尾的文本。

 

Application reaches max limit on rsh connections

It appears from the customer's application that it is reaching the max limit (and even going beyond) on the max allowed number of port connections when doing repeated rsh to the server's in.rshd,-  which allows connections only from the "ephemeral" reserved ports (ports 512-1023).

Many Error Messages of the kind below appear in /var/adm/messages for 5-10 minutes, and, after which connections start to work again.  Customer is getting these error messages at peak load times.  His ultra is a ftp/rsh/rcp server for many differnt remote client machines.

Error msg example: (/var/log/messages)

"Apr  1 11:07:10 asncomm rsh[16295]: can't get stderr port: Resource temporarily unavailable"

The message isn't from xinetd throttling too high of a connection rate. It is from rshd, due to a failure of rresvport. Note that the EAGAIN associated error message translation is documented on the manpage for rresvport:

      “The rresvport() function returns a valid, bound socket descriptor on success.  It returns -1 on error with the global value errno set according to the reason for failure.  The error code EAGAIN is overloaded to mean ''All network ports in use.''

 

参考: rsh的网络通信细节

http://www.netexpert.cn/thread-3717-1-1.html



本文转自 zhenjing 博客园博客,原文链接:   http://www.cnblogs.com/zhenjing/archive/2011/04/20/2021766.html,如需转载请自行联系原作者

相关文章
|
5月前
|
Python
146 python网络编程 - UDP网络通信过程
146 python网络编程 - UDP网络通信过程
24 0
|
8月前
|
Linux 网络性能优化 C++
Linux UDP编程:深入探索无连接通信的实现与应用
在Linux操作系统中,UDP(用户数据报协议)是一种无连接的传输协议,适用于那些对数据传输延迟要求较高、但可靠性要求相对较低的场景。本文将深入探索Linux UDP编程的实现原理与应用,介绍UDP的工作机制、编程接口以及如何在Linux环境下编写UDP程序。
378 0
|
8月前
|
网络协议 Linux 数据库
Linux TCP作为服务器连接方式:建立稳健高效的服务器通信
在Linux服务器开发中,TCP(Transmission Control Protocol)是一种常用的传输层协议,它为服务器与客户端之间的连接提供可靠的、面向连接的通信方式。本文将深入探讨Linux TCP作为服务器连接方式的工作原理,包括服务器端的建立、连接管理和数据传输,以帮助读者建立稳健高效的服务器通信。
223 0
|
9月前
|
缓存 网络协议 Linux
网络通信的神奇之旅:解密Linux TCP网络协议栈的工作原理
深入探索Linux TCP网络协议栈的内部机制,揭开其背后的神秘面纱。通过对TCP协议在Linux系统中的实现方式进行详细解析,了解到它是如何实现可靠的数据传输、拥塞控制和流量管理等关键功能的。 从TCP协议栈的基本构建模块开始,逐步展示数据包在协议栈中的传递过程。通过剖析各个层级的功能模块,包括物理层、链路层、网络层和传输层,我们将揭示每个模块的作用和相互配合的工作方式。同时,我们还将介绍TCP连接的建立、维护和断开过程,以及与之相关的握手机制、超时重传等关键技术。
182 0
网络通信的神奇之旅:解密Linux TCP网络协议栈的工作原理
|
安全 Linux 网络安全
strongSwan报文交互过程
strongSwan报文交互过程
strongSwan报文交互过程
|
存储 监控 网络协议
分享自己平时使用的socket多客户端通信的代码技术点和软件使用
分享自己平时使用的socket多客户端通信的代码技术点和软件使用
213 2
分享自己平时使用的socket多客户端通信的代码技术点和软件使用
|
网络协议 Linux 网络性能优化
Linux网络原理及编程(6)——第十六节 TCP可靠性保证的原理
你在应用层上想要发送一个信息,但是我在底层可能是通过发送多次、甚至有触发了超时重传等等。而站在用户的角度呢,你不用去管它,我传输层不管怎么发,反正最终把你的数据发出去就可以了。也就是说,应用层的传输和底层传输层的并不是一对一、一一对应的关系。
144 0
Linux网络原理及编程(6)——第十六节 TCP可靠性保证的原理
|
JavaScript 网络协议
精简 UDP 服务器
精简 UDP 服务器
68 0
|
SQL 网络协议 安全
Linux网络协议原理
Linux网络协议原理
138 0
Linux网络协议原理
|
存储 缓存 网络协议
QT应用编程: 基于UDP协议设计的大文件传输软件
QT应用编程: 基于UDP协议设计的大文件传输软件
989 0
QT应用编程: 基于UDP协议设计的大文件传输软件