RCP "Permission denied."

[Graeme Nelson]

Trying to rcp (as root) from IBM AIX 4.1.4 to HP/Compaq Tru64 Unix 5.1B and I keep getting "Permission denied."

I have checked /etc/hosts.equiv and /.rhosts and /home/.rhosts and they seem OK. I have tried them with " root" and just "" but to no avail.

Suggestions? Questions?

[Harmanjit_1]

kindly check if entry is there in /etc/hosts also.

[Al Licause]

This subject has been discussed many times in this forum.....so you might want to start by looking back through other entries.

Also try supplying as much detail so responders don't need to ask more questions. The more detail you supply the easier it will be to give a quick accurate answe.


>> I have checked /etc/hosts.equiv and /.rhosts and /home/.rhosts and they seem OK.

What does that mean...."seem OK". Did you check permissions and ownership on these files as well as the content ?

>> I have tried them with " root" and just "" but to no avail.

The problem is on the receiving end....it is the Tru64 system that is rejecting the connection.

The remote or server end tries to backtranslate the incoming ip address into a hostname. It will do so in any number of ways depending on how you've configured your system to do hostname/address translation. Once it finds a name, it then looks for that name string in either hosts.equiv or $HOME/.rhosts. That's where the string needs to match.

Also check for non-printing characters in your Tru64 files....make sure you have no trailing spaces. If these files are in question, try removing and readding the entries or rename the file entirely and recreate the file.

Try running tcpdump to make sure the packets are going where you think they are going and are doing what you think they should be doing.

[Graeme Nelson]

OK. Thanks for the pointers from both of you.


Harmanjit: I have DNS configured and it includes all server names so the /etc/hosts file shouldn't be relevant, but I check that anyway.


Al: Sorry I didn't mention it, but I have already searched these forums for both rcp and rsh postings and nothing I have found within those have resolved this problem.

Yes, root is owner and permissions are 600 (or more). I said they "seem" OK because I wasn't willing to be emphatic as the was still a problem that was probably related to them or their content. Plus the existence of the /home/ direcetory for root's use was confusing as root's "home" directory is actually "/", which is a stupid configuration (even if it is the default): user root's home directory should not be the system root.

I know the problem is at the receiving/Tru64 end, hence my posting here and not in an IBM forum. (Also indicated by my troubleshooting on the Tru64 box and not the AIX box.)

Non-printing characters, extraneous spaces: good ideas, but no.


I prefer to avoid the pain of packet capture and analysis, so I did some more playing with the /.rhosts file:
I added lines with the IP address of the AIX host and "+" - it worked. I removed the "+" and it still worked. I removed the IP address and it stopped working. I added the AIX host to the /etc/hosts file and it worked.

So, it looks like I have a DNS-related name resolution problem with the r-commands back-translate: normal name resolving works OK, including for this AIX host.

Any ideas on this r-command back-translate problem?

(Thanks for the help so far.)

[Al Licause]

A good short cut to determine if a host is correctly back translating incoming ip addresses to their correct names is to telnet or ssh to the remote host in question. Then type tty to find out which psuedo device you are using and finally w | grep {your_device}. The source column is either an ip address or a hostname.

If you see an ip address then your host is not backtranslating at all. If you see the incorrect hostname, then one of the sources for ip address/hostname lookups has an incorrect entry.

If you are running v5.1b tru64unix patch kit 3 or later, the translation is accomplished through the nsswitch.conf file. Prior to this it would be through svc.conf.

Check those files to see what your search order is currently set to and make sure that which ever facility that is performing the translation is doing so correctly.

Adding the ip address to .hosts would indicate that address translation is not working. Adding the name to .hosts might indicate that if translation is working, either the hosts file or the dns entry is incorrect.

The pain of tcpdump can be simplied by limiting the data that is captured to port 514 if your trying to run an rcommand. You don't need to do much analysis....only ensure that first, you are seeing a connection and response to/from the system in question, that the port number is correct and that the correct destination is being touched. If dns is in question use tcpdump to monitor port 53.

In this case you don't care about packet analysis....on the addresses and ports used.

[Graeme Nelson]

svc.conf includes the line "hosts=local,bind,yp"
nsswitch.conf includes the line "hosts: files dns nis"

These tell the same story: resolve hostnames by first looking at the /etc/hosts file, second do a DNS lookup, and finally do a NIS (Yellow Pages) lookup.

The /etc/hosts file resolving obviously works (shown by previous testing mentioned). "Normal" use of DNS works (as previously mentioned), and we don't use NIS here.

Did your suggested telnet - tty - w | grep and it returned the IP address.

Re patch kit level: just T64V51BB24AS0003-20030929 OSF540

What now?

[Al Licause]

The telnet test shows that, an I'm assuing that you telneted from the AIX in question to the Tru64unix system in question.....the backtranslation is not working and so the rcommands would naturally fail.

Try obtaining a copy of freeware tools trace or truss. Then run them while executing the rcommand as such:

trace -w outputfile -P -f telnet hostname

This will show each operating that takes place and each file that is openned. Go through the resulting file and see if the operating is doing what you expect it to do.

You might also want to compare this to a system that is working correctly.

Look for the search operations. It should clearly show an open, read and close for the hosts file and a call to the name resolver if the host entry cannot be found.