X-Win32 Knowledge Base   >   rsh or rexec sessions take a long time to login

Search


About StarNet

StarNet Communications has been a leading developer of X Windows solutions since 1989. After establishing X-Win32 as the de facto standard in the higher education market during the early to mid-1990s -- 150 unlimited Campus Site Licenses worldwide -- X-Win32 has become of one the top three PC X servers in the government and commercial sectors as well.

Unlike its major rivals, Exceed (Hummingbird) and Reflection-X (WRQ/Attachmate), X-Win32 offers a highly focused PC X server that offers superior performance and productivity features, stability, ease of use and low cost (40% or better in most cases).

StarNet also delivers unequaled customer support. Our state-of-the-art engineering infrastructure allows us to fix problems and make a new release available quickly (overnight in many cases). As our testimonials page shows, StarNet customers consistently rate their X-Win32 experience as the best in the industry.




rsh or rexec sessions take a long time to login

X-Win32 rexec and rsh sessions may take a long time to connect (e.g. between 45 seconds and 2 minutes) when connecting to a remote host with a recent operating system or with a patch recently applied to the remote operating system. This is not a problem with X-Win32, it is a side effect of firewalls and the identd check that the remote machine is trying to make to your computer. There are several possible ways to deal with this problem, described below, after further information about the problem.


NOTE: This problem may suddenly appear when you enable the Windows XP SP2 firewall (or another firewall), when you obtain a new remote host with a recent operating system (e.g. RedHat EL 4, Solaris 10, HP-UX 11, AIX 5, SuSE 9.3, Ubuntu, Debian, FreeBSD 6.1, etc.), or when you install a patch to an older operating system (which may replace the default inetd config file that you were previously using). Also note that this problem would apply to any product attempting to make an rexec or rsh connection from your Windows machine to your remote host; there is no problem in any particular version of X-Win32 or X-Win32 in general.

Why the delay occurs

  1. rexec and rsh are inherently insecure protocols (they do not encrypt data nor passwords and they allow logins by a simple user name or host name match); consider using StarNetSSH sessions instead
  2. Because rexec and rsh are insecure, operating system vendors have adopted a policy of logging as much information as possible about each rexec and rsh connection so that an internal malicious user could be identified in the event of a security breach; part of the information collected is the login name of the remote user (i.e. the X-Win32 user on the Windows machine) via the identd service
  3. The identd service, usually run via the inetd service (NOTE: inetd and identd, though they look similar in name, are entirely different) when it handles an incoming rexec or rsh connection request, attempts to make a connection back to your X-Win32 Windows machine to the identd service to obtain the login name for the incoming rexec or rsh connection request; oddly enough, if the identd connection fails, the rexec or rsh connection is still allowed. There are two problems with this approach:
    1. Windows machines do not have an identd service; normally, this would cause the identd connection to fail immediately, allowing the rexec or rsh connection to proceed immediately; however, the point below then comes into effect.
    1. Windows machines may have a firewall enabled on them, particularly if it is Windows XP SP2 or later, which includes a builtin firewall that is on by default.
  4. Firewalls cause a problem because, instead of sending back a packet to the remote host indicating that there is no identd service, they instead simply fail to answer the request for the identd request. This is intentional and makes it much more difficult for crackers to obtain information about your Windows machine. However, this causes the identd connection timeout to come into effect.
  1. Unfortunately, the identd service has a ridiculously high timeout value of between 45 seconds and 2 minutes; when the X-Win32 machine has a firewall (e.g. Windows XP SP2) then the identd service cannot detect that the connection has failed and must wait the full timeout period to determine that the connection has failed; only after the timeout is reached is the rexec or rsh connection allowed to proceed.

    How to avoid the delay

  2. Use StarNetSSH instead of rexec or rsh sessions. The SSH protocol is secure in the way that it transmits data and authenticates connections, thus, operating system vendors do not require the identd lookup for SSH connections. Switching to StarNetSSH sessions is really the best solution, as the SSH protocol is also able to cross other firewalls and is not susceptible to misconfigured reverse DNS lookups. See Xdmcp session: Cannot open display with different address for more information on reverse DNS problems.
  3. Open TCP port 113 on your Windows XP SP2 firewall; this will cause the identd connection to be immediatley rejected since no such service is actually running on your Windows machine, thus allowing the rexec or rsh connection to proceed immediately. This approach has very little risk since there is not actually a service running on the port that you have opened in your firewall.
  4. Disable the identd lookup for rexec and rsh in your inetd configuration file (e.g. /etc/inetd.conf); this approach is mildly risky
  5. Disable the firewall on your Windows machine; this is not recommended at all, as this will make your

machines vulnerable to worms being passed around on your internal network

Category:Sessions -> rexec
Category:Sessions -> rsh
Category:FAQ