Description of problem:
I'm getting intermittent failure when trying to login in
to an FC3 box using rlogin. All the client side gets is
a "connection closed" message. There are no errors logged
on the server side.
Version-Release number of selected component (if applicable):
Easy but not 100%.
Steps to Reproduce:
1. Install rsh-server.
2. Enable rlogin in /etc/xinetd.d/rlogin and restart xinetd.
3. In a user account on the server set up a ~/.rhosts file for
password-free login from some other host.
4. From that other host repeatedly try to rlogin to the server.
Sometimes it will work. Sometimes it will fail with a "connection
closed" message. Sometimes it will work but take unusually long
time (several seconds) to complete the connection.
Successful connection every time.
I don't know if it's related or not, but after a successful login
this error is written to /var/log/secure on the server side upon
logging back out:
Nov 28 18:50:36 chinook login: Warning! Could not relabel /dev/pts/2
with user_u:object_r:devpts_t, not relabeling.
1/ Dont't forget if you call "rsh" without command it uses "rlogin".
It means in this case you need to enabled "rlogin" in the
/etc/xinetd.d/rlogin too. For testing is good use something like:
"/usr/bin/rsh <host> ls".
2/ You need to add "rsh", "rlogin" to /etc/securetty too.
3/ Must be possible connect from server to client. The rsh/rlogin uses
reverse (stderr) connection. So there is two(!) connections,
client->server and server->client. Maybe you can try disable iptables
(service iptables stop) for your tests.
4/ Your server must be enable convert client IP to full client hostname.
5/ in the file ~/.rhosts is required full client hostname.
If you have still a problem connect to your server, please add to your
bugreport "strace" outputs:
$ strace -f -o client.trace /usr/bin/rsh <host>
Server (it's more dificult):
- create shell script:
/usr/bin/strace -f -o /tmp/server.trace /usr/sbin/in.rshd
- add path to this script to /etc/xinetd.d/rsh (options server=)
- restart xinetd (service xinietd restart)
- check the file /tmp/server.trace on server after failed connection
Note: with strace on client you can have a permission problem as
None of ideas #1 through #5 would explain the intermittent nature
of the problem. When I say intermittent I really mean it. One
second it will work. A few seconds later it will fail. A few seconds
later it might work again. That's not a problem with my system
I'm attaching two client-side strace output files. One shows a
successful rlogin and the other a failure. In the successful case
you can see where it makes the connection, reads "exit\n" as I type
it in at the remote shell prompt, and the session is closed normally.
In the failure case you can see that the connection is initially
successful but at the point where the remote shell (bash) tries
to read a command from stdin it gets an ERESTARTSYS error code and
the session is terminated. This is wrong. It's as though the
ERESTARTSYS error code is being treated as a real error instead of
a request to restart the system call.
Created attachment 107819 [details]
Client-side strace of a successful rlogin
Created attachment 107820 [details]
Client-side strace of a failed rlogin.
Thanks for your strace outputs. You didn't use "-f", so in your strace
output missing client child process that read data from server (client
uses two processes).
Please, can you do it again and for server too. And --please-- use
"-f" option for strace :-) I don't see problem in your actual strace
output, but we don't know why client child process was exited.
ERESTARTSYS is only ptrace information about kernel internal stuff and
it doesn't return to userspace. It's no problem.
Please, check your server PAM setting. The "rlogin" use it and for
example pam_limits setting can disable login to server if there is
used all user's resources.
I am also having this problem. It did not appear to happen until
after I updated all of the packages on the system. Booting into the
stock kernel seems to solve the problem for now. I have used the same
configuration successfully on a RH9 system.
Thought I'd add that the error only happens once in a while, and I
can't seem to tie it down to any particular happening. I executed the
same command twice within seconds of each other and one failed and
one was successful. I happened to be strace'ing the execution (as
shown above with the -f) and will be attaching them.
Created attachment 108391 [details]
sucessful client side trace
Created attachment 108392 [details]
un-sucessful client side trace
Make, can you try server side (rlogind) strace too. I think client
side looks without problems.
By the way, "rsh" without command, calls "rlogin".
I'm currently strace'ing the rlogin as shown above and now the
problem doesn't occur. Is there a possiblity of a timing issue that
strace is taking care of. The reason that I mention this is that
rlogin seems a little bit slower than when it isn't running through
strace on the server. I've tried around 600 rlogins and haven't had a
problem. Seems kinda wierd to me.
It looks like bug #137808 -- this bug isn't possible detect with
strace or gdb :-( The problem is somewhere around place where the
"login" tries initialize pseudo terminal.
Too bad some of us aren't authorized to see #137808.
So, has anyone found a solution for this? I also am interested, and
am also unable to view #137808
Can anyone confirm this bug on actual FC4?
Closing due to lack of response.
FC3 is the responsibility of Fedora Legacy now, and this is not
a security issue. (Indeed, using rlogin rather than ssh is more
of a security issue.) If this occurs in FC4 or FC5, please reopen.