Description of problem:
Let's get the ball rolling on this one...
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Created attachment 522486 [details]
Created attachment 522487 [details]
Created attachment 522488 [details]
Created attachment 522492 [details]
Created attachment 522493 [details]
Created attachment 522494 [details]
Passes simple telnet test and note there is still a (tight) window to have this
Once package and shipped your package should no longer have to depend on xinetd
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.
(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)
More information and reason for this action is here:
rsh-0.17-71.fc19 has been submitted as an update for Fedora 19.
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rsh-0.17-71.fc19'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
rsh-0.17-71.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.
rsh fails between two machines having only IPV4 adresses if one uses
the new rsh.socket systemd file to activate it.
The error message ares: (IPs and names made anonymous):
rshd: Host addr ::ffff:X.Y.Z.T not listed for host A.B.C
rshd: rsh denied to root@A.B.C as root: Host address mismatch for %s
It works if:
- one starts this service the old way with xinetd
- or if one change rsh.socket to use IPV4, ie:
where a.b.c.d is the IP number of the machine
I was trying to reproduce the issue. I used two clean Fedora installations with out of box settings, except IPv6, which I disabled entirely on both hosts. I tried rsh and rlogin and it worked as expected.
Can you describe your environment and settings in greater detail?
> Can you describe your environment and settings in greater detail?
Our network uses a DHCP and DNS IPv4 only servers. The fedora machines
have IPv6 enabled and obtain their IPs through DHCP.
You can reproduce this problem on a single machine as follows:
- configure it to use IPv6 (the default)
Then rsh.socket will listen on IPv6 only (see below), while
allowing IPv4 connections (with IPv4-on-IPv6 if I understand
- add localhost4 to /root/.rhosts
rsh localhost4 hostname
Host address mismatch for localhost
May 1 08:40:57 local36 systemd: Starting Remote Shell Facilities Server...
May 1 08:40:57 local36 systemd: Started Remote Shell Facilities Server.
May 1 08:40:57 local36 rshd: Host addr ::ffff:127.0.0.1 not listed for host localhost
May 1 08:40:57 local36 rshd: rsh denied to root@localhost as root: Host address mismatch for %s
May 1 08:40:57 local36 rshd: rsh command was 'hostname'
rsh.socket listen on IPv6 only, unlike ssh that listen on IPv4 and
lsof -i tcp:514,22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd 1 root 56u IPv6 41015 0t0 TCP *:shell (LISTEN)
sshd 777 root 3u IPv4 16626 0t0 TCP *:ssh (LISTEN)
sshd 777 root 4u IPv6 16628 0t0 TCP *:ssh (LISTEN)
Looking at the sources, I think that it should suffice to modify the
in the findhostname function, replace the call of inet_ntop that
initialize remote_address by:
getnameinfo (fromp, fromlen, remote_address, INET6_ADDRSTRLEN,
NULL, 0, NI_NUMERICHOST)
rewrite the soaddr_eq_ip function to handle v4-mapped-on-v6
I may try to do that myself. Let me know.
I saw that you updated recently the RPM to the version 0.17-72
- fix handling of non-native IPv6 connections via AF_INET6 socket
I tested it, and it works.
Thanks a lot.