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.
NOTE: Posting from groups.google.com (or some web-forums) dramatically reduces the chance of your post being seen. Find a real news server.
A lot depends on what is running on the remote system, and what you are actually trying to accomplish.
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.
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)?
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
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.
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.
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'.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.