The initial TCP/IP connection is based on the results of nslookup on the name of the remote host. This gives an IP address which is used as a destination. The routing table (netstat -rn) is then consulted to determine which interface to use and which is the next hop (gateway). The packet is then sent on to the gateway which forwards it on to the destination. The packet is normally addressed to port 514 since rcp rides on the rsh protocol. If the host is listening on 514 then the threeway handshake completes (return packets being sent to the source address using the local routing table). The TCP/IP stack then passes the ball to the rshd.
From
http://www.private.org.il/mini-tcpip.faq.html#4.%20Of%20the%20rsh%20protocol."The rshd listens on TCP port #514. The following info is from the unix rshd man pages :
Service Request Protocol
When the rshd daemon receives a service request, it initiates the following protocol:
The rshd daemon checks the source port number for the request. If the port number is not in the range 0 through 1023, the rshd daemon terminates the connection.
The rshd daemon reads characters from the socket up to a null byte. The string read is interpreted as an ASCII number (base 10). If this number is nonzero, the rshd daemon interprets it as the port number of a secondary stream to be used as standard error. A second connection is created to the specified port on the client host. The source port on the local host is in the range 0 through 1023."
Note: We still have not done any reverse lookup so this optional new connection is made to the original source ip using the requested port and follows the same return path as the replies to the initial connection. This is sort of similar to what ftp does so it may have trouble passing a firewall. This inability to create the stderr back channel connection could cause the thing to hang. It might be interesting to do a
netstat -an |grep a.b.c.d
where a.b.c.d is the ip address of the remote system (and the remote system is on the local subnet to eliminate firewall or router problems) to see if we use one or two connections to do an rcp.
"The rshd daemon uses the source address of the initial connection request to determine the name of the client host. If the name cannot be determined, the rshd daemon uses the dotted decimal representation of the client host's address."
Note: Here we do a reverse lookup of the source IP address to see who started the session.
nslookup a.b.c.d
where a.b.c.d is the source address of the tcp/ip connection.
If this fails we will use the source ip address when we try to authenticate. You should try this on the remote system to see what result you get.
"The rshd daemon retrieves the following information from the initial socket:
A null-terminated string of at most 16 bytes interpreted as the user name of the user on the client host.
A null-terminated string of at most 16 bytes interpreted as the user name to be used on the local server host.
Another null-terminated string interpreted as a command line to be passed to a shell on the local server host. "
Note: In the case of rcp the two user names are the same tho rsh has provisions for using two different names and the command line will do the actual copying. I've never looked at it on a sniffer but I expect it is really something like
cat localhost:localfile1 > remotehost:remotefile1.
"The rshd daemon attempts to validate the user using the following steps:
The rshd daemon looks up the local user name in the /etc/passwd file and tries to switch to the home directory (using the chdir subroutine). If either the lookup or the directory change fails, the rshd daemon terminates the connection."
Note: Here is another thing you can check. Does the user name exist in the /etc/password file and is there a home directory for the user name? Can we write in it if logged in as the user?
"If the local user ID is a nonzero value, the rshd daemon searches the /etc/hosts.equiv file to see if the name of the client workstation is listed. If the client workstation is listed as an equivalent host, the rshd daemon validates the user.
If the $HOME/.rhosts file exists, the rshd daemon tries to authenticate the user by checking the .rhosts file."
Note: Immediately above is the first use of the info from the nslookup a.b.c.d. Is the name we got back from nslookup a.b.c.d in the $HOME/.rhosts? Does the file even exist?
"If either the $HOME/.rhosts authentication fails or the client host is not an equivalent host, the rshd daemon terminates the connection.
Once rshd validates the user, the rshd daemon returns a null byte on the initial connection and passes the command line to the user's local login shell. The shell then inherits the network connections established by the rshd daemon."
So you see it really does not care what you have in /etc/hosts for the name since we do a reverse lookup of the IP address. If it does not appear in /etc/hosts then we ask the DNS server who hopefully has the right answer. Even if the command succeeds there may still be a message sent back to the stderr and it is possible depending on how the software is written that we may suddenly discover that there is no stderr channel open and hang here with the real job done but unable to complete because it can't send the "I made it" message. Near as I can tell the data passes over the original connection and the second connection is only used for stderr.
Ron
