help with remote input commands thru rsh

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi friends,

I'm writing a shell script to connect to a remote embedded system and
do a few operations thru the Linux system on the embedded system. I
didn't know how to send commands in my shell script to the remote
system because these commands are considered commands for my host
Linux.

I looked it up and found that rsh should remote-mount the remote
system onto my Linux host as a remote shell and my commands can be
sent over directly. However, when I tried, I got:

rsh 192.168.247.178 -l root
rsh: remote terminal session not supported

The remote system recognises the rsh command. I looked it up again and
added my host's ip address to hosts.allowed but it didn't work.

Another question about rsh is: do I have to append "rsh
192.168.247.178 -l root" to every command or I just need it once? I
don't know if rsh telnets the remote machine every time when it sends
over a command or it telnets the remote machine once and sends over
all the commands following.

Does anyone know the answers?

Thanks,
Sam


Re: help with remote input commands thru rsh
On Thu, 08 Nov 2007, in the Usenet newsgroup comp.os.linux.embedded, in article

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen.  Find a real news server.

Quoted text here. Click to load it

A lot depends on what is running on the remote system, and what you
are actually trying to accomplish.

Quoted text here. Click to load it

Poorly stated - you aren't mounting anything. The Berkeley 'r' commands
(there are a number of them besides 'rsh') were developed in the early
1980s in a completely different atmosphere.   They have long been
deprecated as totally insecure - they depend on hostnames (easily
spoofed), and pass everything over the local network as clear text.

Quoted text here. Click to load it

<CRINGE!!!>

OK, first - root is _RARELY_ allowed to log in over the network,
much less run unauthenticated.  Second, that looks like the remote
is refusing the session (which is not surprising).  Does the remote
system have a non-privileged user such as 'sam' and did you set up
the "authentication" files for that user?  If so, can you run 'rsh'
as that user (rather than root)?

Quoted text here. Click to load it

You REALLY want to find a more secure mechanism - ssh is a good start.
Second, the file you might be referring to is '/etc/hosts.allow' and
it's only consulted if the server is configured to use it.  For an
older system using /sbin/inetd, the line in /etc/inetd.conf would
look like

  shell  stream  tcp     nowait  root    /usr/sbin/tcpd  in.rshd

Notice it's calling '/usr/sbin/tcpd' with the argument 'in.rshd'.
If you were using the newer xinetd (and thus have a file named
/etc/xinetd.d/rsh or similar), the xinetd daemon may check the
hosts.allow file.   However, the rsh daemon should ALSO be checking
it's authentication file /etc/hosts.equiv and the .rhosts file found
in the user's home directory.  It also needs to be able to match up
the address and hostnames, so either you need DNS working, or the
client you are logging in _from_ needs to be listed in the server's
/etc/hosts file.   See the man page for 'rsh' (client) and 'in.rshd'
(server). You may also need to be looking at the PAM man pages if
the server is using PAM, and the super-server ('inetd' or 'xinetd')
as appropriate, and the 'hosts_access'(5) man page for the setup
of tcpwrappers.

Quoted text here. Click to load it

That won't work for root - but yes, you need to use that prefix
every time you send _a_ command because 'rsh' runs a single command
and then exits.

Quoted text here. Click to load it

No, 'rsh' (and the similar 'rexec') and completely different protocols
from the equally insecure 'telnet'. There is also a 'rlogin' service
that runs multiple command using the same (lack of) authentication as
'rsh'.

        Old guy

Site Timeline