配置rhel4的rsh,rexec,rlogin

HowTo - rsh, rlogin, rexec
-- for Red Hat Linux distributions --

Karel Zak redhat.com>
13-Dec-2004

I. Enable rsh (or rlogin, ...)

1) /etc/xinetd.d/rsh

	service shell
	{
		socket_type             = stream
		wait                    = no
		user                    = root
		log_on_success          += USERID
		log_on_failure          += USERID
		server                  = /usr/sbin/in.rshd
		disable                 = no
	}

The option " disable" set to "no".

2) Restart your "xinetd" daemon:

	service xinetd restart

3) /etc/securetty
Don't forget check if "rsh" (or "rlogin", ...) is there.

4) Check connection from server to client.
All r[sh | login | exec] utils use two connections. One from client to server and second from server to client.

• - check you client side iptables (firewall, NAT, ...)

5) Check if you server is able to convert client IP address to hostname.

• - check DNS or /etc/hosts

6) Check your ~/.rhosts

• - the best file permissions are "-rw-------"
  - the client hostname must be full hostname, an example:

	foo.bar.com zakkr

7) Check your /etc/pam.d/rsh (or rlogin, ...)

• - for example module "pam_nologin.so" can disable login if the file

/etc/nologin exists. For more details read /usr/share/doc/pam-0.77/txts/README.pam_nologin 8) Never change /etc/pam.d/rsh to use somethimeg other than:

	auth       required     pam_rhosts_auth.so 

The client-server "rsh" protocol is not designed for other authentication than by .rhost files. For example pam_stack.so in section "auth" can corrupt the client/server connection if the "login" program sends password prompt to client. If you need authentication by password use "rlogin" or "ssh".

II. Notes

1) "rsh" with and without are not same commands

• "/usr/bin/rsh " = is same as "rlogin ". It means you need to enabled "rlogin" on server!
  "/usr/bin/rsh = this is normal "rsh"

2) In the Red Hat distributions you can found kerberosized versions of "rsh" (or "rlogin", ...).

• "rsh" without exact path can be interpreted as "/usr/kerberos/bin/rsh".

If you don't need the kerberized version it is better to use absolute path to rsh. You will save yourself the kerberos checking and an execution of the original "rsh" if the kerberos auth fails.

III. Limits

1) The number of privileged ports is limited. The rsh (or rlogin, rcp, ...) uses privileged ports 512-1023. If all ports are used there is no space for a new connection. To check your server's ports status do:

	netstat -n --inet

2) TCP/IP connections doesn't end instantly but uses the TIME_WAIT state. The timeout of this state is cca 60s. It's possible that all your reserved ports are in TIME_WAIT state if you use connect and disconnect to server very very often.

IV. Troubleshooting

1) Check /var/log/messages. You can found there a lot of interesing information.

2) Your friend is "strace" program.

a) client:

		strace -f -o rsh-client.strace /usr/bin/rsh 

Don't forget to user the "-f: option, it's important.

b) server:

- create shell script. "/root/rsh-strace.sh"

		#!/bin/bash
		/usr/bin/strace -f -o /tmp/rsh-server.trace /usr/sbin/in.rshd

- change your /etc/xinetd.d/rsh

		service shell
		{
			socket_type             = stream
			wait                    = no
			user                    = root
			log_on_success          += USERID
			log_on_failure          += USERID
			server                  = /root/rsh-strace.sh
						#/usr/sbin/in.rshd
			disable                 = no
		}

The " server" option should be the path to the strace script.

- restart xinetd daemon

THIS DOCUMENT IS DEPRECATED

Configuring .rhosts

.rhosts is used to control which machines trust other machines for access to your account. If a machine trusts another machines then it will allow a specified user (usually yourself) to access your account without having to enter a password.

This has an obvious advantage (apart from saving typing) - your password does not have to travel across the network. On the other hand, it does means that if your account on the other machine is compromised, it's trivial to get access to your accounts on other machines. Think carefully about which machines you put in your .rhosts file.

.rhosts is not suitable for allowing access to machines which are not handling IP 24 hours a day. (If your machine is switched off, it's much easier to take over its IP address and spoof the trusted machine.) The secure shell, ssh, has a replacement for the r-utilities (rcp, rlogin, rsh) which doesn't suffer from this problem.

rlogin

Unix provides a command called rlogin for easy login to remote machines. Here is a simple example of its use:

gryphon$ rlogin hammer.thor
Password:
Last login: Mon Oct 11 13:10:02 from gryphon.csi.cam.ac.uk
Solaris Release 2.5 [hammer] Linux Redhat Release 4.2 [gloves,belt] (Thor)

hammer$

By default, rlogin will connect me to the remote machine with an account name the same as my name on the local machine (rjd4 in this case). Note that my Thor password was required.

.rhosts

It is possible to make my account on hammer "trust" my account on gryphon. To do this, I create a file, .rhosts, in my home directory on hammer containing all the machines on which it is to trust my account. If I rlogin from one of thse machines to hammer I will not be asked for a password. This file must be readable only by the user.

Suppose I have the following .rhosts file on hammer.

hammer$ cat .rhosts
gryphon.csi.cam.ac.uk
oneeye.csi.cam.ac.uk

If I rlogin from gryphon or oneeye I will not be prompted for my password.

gryphon$ rlogin hammer.thor
Last login: Mon Oct 11 13:10:02 from gryphon.csi.cam.ac.uk
Solaris Release 2.5 [hammer] Linux Redhat Release 4.2 [gloves,belt] (Thor)

hammer$

Never put a "+" in a .rhosts file; it means "every machine".

Suppose I have an account on gryphon called "bob" and an account "rjd4" on hammer. On gryphon I issue the command
gryphon$ rlogin -l rjd4 hammer.thor.cam.ac.uk
and my (rjd4's) .rhosts file on hammer contains the line
gryphon.csi.cam.ac.uk bob
and then the "trust" still works.

Remote shells

It is also possible to submit single instructions to a remote machine rather than logging in, issuing the instruction and logging out again. This is done with the rsh command.

For this command to work, the account on the remote machine must trust the account on the local machine. There is no opportunity to issue apassword.

Consider the following example.

gryphon$ rsh hammer.thor.cam.ac.uk ls -l | wc -l
     21
gryphon$

The rsh causes a shell to be started on hammer. This shell runs ls -l and its standard output is piped back over the network into the standard input of wc -l which is run locally.

If the account names differ on the two systems then the -l syntax must be used again.

gryphon$ rsh -l rjd4 hammer.thor.cam.ac.uk uname -n
hammer.thor.cam.ac.uk

There is an important point that must be noted about the remote shell started by rsh: it is not a login shell. The .profile or .bash_profile files are not sourced so any configuration they do will not be done for this shell. What happens instead depends crucially on the shell. Under bash the .bashrc file is read instead.

Remote file copying

To copy files from one machine to another, the rcp command can is provided. This has an identical syntax to cp but filenames can be preceded by "machine:".

gryphon$ rcp hammer.thor:trial.pl test.pl
gryphon$ rcp Unix.tex gloves.thor:~/unix/source.tex

If the account names differ then the filenames are further extended. (NB The -l is not used.)

gryphon$ rcp rjd4@hammer.thor:trial.pl test.pl

As with rcp the .rhosts file must be set up on the remote machine to trust the local machine.

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9240380/viewspace-628880/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9240380/viewspace-628880/