First.... No need to bring up the ssh v.s. telnet stuff.....
Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
1. yum install telnet-service 2. opened telnet port on the firewall (not that it mattered since local also fails) 3. chkconfig telnet on 4. systemctl restart xinetd.service
When I telnet in (remote or local) I get this....
[egreshko@meimei ~]$ telnet f18x Trying 192.168.0.168... Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) Connection closed by foreign host.
And this ends up in /var/log/messages....
Jan 29 11:41:29 f18x xinetd[4488]: START: telnet pid=4665 from=192.168.0.18 Jan 29 11:41:29 f18x xinetd[4488]: EXIT: telnet status=0 pid=4665 duration=0(sec)
However, if I add
server_args = -D options
to the /etc/xinetd.d/telnet file it "works". But, of course, I get debug info that I don't want....
The same procedure in F17 works fine....
What could I be missing?
On Tue, Jan 29, 2013 at 11:46:58 +0800, Ed Greshko Ed.Greshko@greshko.com wrote:
First.... No need to bring up the ssh v.s. telnet stuff.....
Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
Most people aren't going to be running telnetd as passwords are transmitted in the clear and you need to trust that no one is sniffing passwords. At the local endpoint networks this isn't that hard to do.
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
On 01/29/2013 09:53 PM, Bruno Wolff III wrote:
On Tue, Jan 29, 2013 at 11:46:58 +0800, Ed Greshko Ed.Greshko@greshko.com wrote:
First.... No need to bring up the ssh v.s. telnet stuff.....
Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
Most people aren't going to be running telnetd as passwords are transmitted in the clear and you need to trust that no one is sniffing passwords. At the local endpoint networks this isn't that hard to do.
Thank you for ignoring the very first sentence and reciting the obvious.
On Tue, Jan 29, 2013 at 22:19:24 +0800, Ed Greshko Ed.Greshko@greshko.com wrote:
Thank you for ignoring the very first sentence and reciting the obvious.
Sorry about that. I saw two threads about it and didn't read the second one very carefully.
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
On 01/29/2013 10:23 PM, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
FWIW, I get the failure on an F18 system running in VM. However, it "works" on another F18 system running real HW. But, it fails as described in the fedora-test list.
On 01/29/2013 10:22 PM, Bruno Wolff III wrote:
On Tue, Jan 29, 2013 at 22:19:24 +0800, Ed Greshko Ed.Greshko@greshko.com wrote:
Thank you for ignoring the very first sentence and reciting the obvious.
Sorry about that. I saw two threads about it and didn't read the second one very carefully.
OK.....
FWIW, there are times where telnet is the only viable option. We have an internal system running a real old version of Unix used for X.400/X.25 communication for which ssh is not an option.
.
FWIW, there are times where telnet is the only viable option. We have an
internal system running a real old version of Unix used for X.400/X.25 communication for which ssh is not an option.
But that would be the unix server running telnet and not the Linux system as in this case....
There's very few, if any, reasons for a Linux server today to be running a telnet server instead of our alongside ssh...
On 01/30/2013 02:56 AM, James Hogarth wrote:
.
FWIW, there are times where telnet is the only viable option. We have an internal system running a real old version of Unix used for X.400/X.25 communication for which ssh is not an option.
But that would be the unix server running telnet and not the Linux system as in this case....
No, you are wrong. The client side is the Unix box and the server side is the Linux box. Additionally, the telnet client isn't what you assume it to be.
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
{^_^}
On 01/30/2013 09:37 AM, jdow wrote:
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
No, I eliminated that early on.... Another manifestation of the problem is "garbled" output....
Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) 18x login: assword: ast login: Wed Jan 30 08:27:30 on :0 ]0;egreshko@f18x:~[?1034hegreshko@f18x ~]$ [0mDesktop Documents Downloads Music Pictures Public Templates Videos
For which a bugzilla has already been filed.
On 2013/01/29 17:49, Ed Greshko wrote:
On 01/30/2013 09:37 AM, jdow wrote:
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
No, I eliminated that early on.... Another manifestation of the problem is "garbled" output....
Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) 18x login: assword: ast login: Wed Jan 30 08:27:30 on :0 ]0;egreshko@f18x:~[?1034hegreshko@f18x ~]$ [0mDesktop Documents Downloads Music Pictures Public Templates Videos
Erm, you said it's a very old machine. I get the impression it is using telnet to get to the Linux machine. What you're seeing looks for all the world like what people used to see on RS232 terminals when flow control was disabled. Is flow control disabled somewhere in your network path between the machines? If it is a very slow machine may get hit with data faster than it can parse it.
{^_^} Joanne (If I'm right old age and guile once again defeats youth and enthusiasm. {^_-} If not - "Never mind.")
On 01/30/2013 10:00 AM, jdow wrote:
On 2013/01/29 17:49, Ed Greshko wrote:
On 01/30/2013 09:37 AM, jdow wrote:
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
No, I eliminated that early on.... Another manifestation of the problem is "garbled" output....
Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) 18x login: assword: ast login: Wed Jan 30 08:27:30 on :0 ]0;egreshko@f18x:~[?1034hegreshko@f18x ~]$ [0mDesktop Documents Downloads Music Pictures Public Templates Videos
Erm, you said it's a very old machine. I get the impression it is using telnet to get to the Linux machine. What you're seeing looks for all the world like what people used to see on RS232 terminals when flow control was disabled. Is flow control disabled somewhere in your network path between the machines? If it is a very slow machine may get hit with data faster than it can parse it.
The justification for needing a working telnet server is that the client side is old.
The problem was discovered and occurs on F18 itself with "telnet localhost".
On Tue, Jan 29, 2013 at 7:49 PM, Ed Greshko Ed.Greshko@greshko.com wrote:
On 01/30/2013 09:37 AM, jdow wrote:
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
First.... No need to bring up the ssh v.s. telnet stuff..... Has anyone configured telnetd for use on F18? Running 64 bit....but
this shouldn't make a difference. Anyway, I did the normal procedure.....
I just did, and I didn't add -D, but I did change "disabled = yes" to
"no"
in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
No, I eliminated that early on.... Another manifestation of the problem is "garbled" output....
Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) 18x login: assword: ast login: Wed Jan 30 08:27:30 on :0 ]0;egreshko@f18x:~[?1034hegreshko@f18x ~]$ [0mDesktop Documents Downloads Music Pictures Public Templates Videos
For which a bugzilla has already been filed.
My question may be a red herring, but could there be anything in your .bash_profile, .bashrc, ... etc files behaving differently between F17 and F18, causing problems during telnet login?
On 2013/01/29 18:07, Ed Greshko wrote:
On 01/30/2013 10:00 AM, jdow wrote:
On 2013/01/29 17:49, Ed Greshko wrote:
On 01/30/2013 09:37 AM, jdow wrote:
On 2013/01/29 06:23, Ed Greshko wrote:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote: > First.... No need to bring up the ssh v.s. telnet stuff..... Has > anyone configured telnetd for use on F18? Running 64 bit....but > this shouldn't make a difference. Anyway, I did the normal > procedure..... I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
SELinux getting in the way in one of the two cases?
No, I eliminated that early on.... Another manifestation of the problem is "garbled" output....
Connected to f18x. Escape character is '^]'. Fedora release 18 (Spherical Cow) Kernel 3.7.4-204.fc18.x86_64 on an x86_64 (3) 18x login: assword: ast login: Wed Jan 30 08:27:30 on :0 ]0;egreshko@f18x:~[?1034hegreshko@f18x ~]$ [0mDesktop Documents Downloads Music Pictures Public Templates Videos
Erm, you said it's a very old machine. I get the impression it is using telnet to get to the Linux machine. What you're seeing looks for all the world like what people used to see on RS232 terminals when flow control was disabled. Is flow control disabled somewhere in your network path between the machines? If it is a very slow machine may get hit with data faster than it can parse it.
The justification for needing a working telnet server is that the client side is old.
The problem was discovered and occurs on F18 itself with "telnet localhost".
Oh really! You mean Alan Cox was right about F18? Hm....
...
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning." -- Rick Cook, The Wizardry Compiled
Joanne's restatement: "No matter how idiot proof a programmer makes his system, God will provide a better idiot."
{^_^}
On 01/30/2013 10:13 AM, Richard Sewill wrote:
My question may be a red herring, but could there be anything in your .bash_profile, .bashrc, ... etc files behaving differently between F17 and F18, causing problems during telnet login?
Very doubtful for 3 reasons.....
1. the user account testing has the stock .bash* files in home directory. No changes.
2. That would not explain the immediate disconnect issue.
3. I have also found the immediate disconnect issue happens 95% of the time but sometimes a connection is made but with the garbled output.
On 01/28/2013 07:46 PM, Ed Greshko wrote:
Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference.
Actually, it might. I ran strace on the telnetd process, which should mostly proxy data between a child process (login, at that point) and the socket. It isn't. I just looked at the spec in git; there don't appear to be any changes since F17. Any bug that's new to F18 would have to be external to telnetd's source.
As long as you're concerned with compatibility over security, have you considered using rsh instead? As much a problem as telnet is where security is involved, the biggest one you face now is finding anyone motivated to fix it. telnetd is more complicated than you think, probably. It's not a simply proxy to a local process/tty. The client and server actually exchange a bunch of options in a binary handshake. Finding the bug could take a while if you can't get the author's attention, and I don't think that code has been maintained for a long time.
Ed Greshko <Ed.Greshko <at> greshko.com> writes:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
<SNIP>
Has anyone configured telnetd for use on F18?
<SNIP>
I just did, and I didn't add -D, but I did change "disabled = yes" to "no" in the telnet xinetd config. And it just worked.
Thanks for testing.
That is what I did too.... And it fails as described. I'm stumped.
Seeing the same problem here that Ed saw. I am seeing one interesting twist that Ed didn't mention. If I start the telnet server on my F18 box with something like "server_args = -D report", I can login locally. If I try to log in from a different box, I get a "no route to host" message which is bogus since I can ping the F18 system or ssh to it. I messed with hosts.allow and hosts.deny but didn't see any change.
Maybe the problem isn't in telnetd but in tcp wrappers instead.
All testing is being done with iptables stopped and SELinux in permissive mode.
Cheers, Dave
On 01/30/2013 01:54 PM, Gordon Messmer wrote:
On 01/28/2013 07:46 PM, Ed Greshko wrote:
Has anyone configured telnetd for use on F18? Running 64 bit....but this shouldn't make a difference.
Actually, it might. I ran strace on the telnetd process, which should mostly proxy data between a child process (login, at that point) and the socket. It isn't. I just looked at the spec in git; there don't appear to be any changes since F17. Any bug that's new to F18 would have to be external to telnetd's source.
Well, you brought up an interesting point. And, indeed, it does seem to be something external to telnetd. The version of f17 is 0.17-53 while f18 is 0.17-54. So made the mistake, again, of assuming.
I just installed the f17 rpm on the f18 system and it fails in the same way.
As long as you're concerned with compatibility over security, have you considered using rsh instead? As much a problem as telnet is where security is involved, the biggest one you face now is finding anyone motivated to fix it. telnetd is more complicated than you think, probably. It's not a simply proxy to a local process/tty. The client and server actually exchange a bunch of options in a binary handshake. Finding the bug could take a while if you can't get the author's attention, and I don't think that code has been maintained for a long time.
Sorry, not looking for a replacement. I'm also not going to explain the environment which makes changing things impossible. If it never gets fixed, well so be it. It only affects 2 users in a closed environment. Not upgrading their systems to f18 won't impact their ability to do their jobs so their management could care less. Their management would probably prefer they used RHEL or CentOS anyway.
On 01/30/2013 02:42 PM, David G. Miller wrote:
Ed Greshko <Ed.Greshko <at> greshko.com> writes:
On 01/29/2013 10:19 PM, Matthew Miller wrote:
On Tue, Jan 29, 2013 at 11:46:58AM +0800, Ed Greshko wrote:
<SNIP> >>> Has anyone configured telnetd for use on F18? <SNIP> >> I just did, and I didn't add -D, but I did change "disabled = yes" to "no" >> in the telnet xinetd config. And it just worked. > Thanks for testing. > > That is what I did too.... And it fails as described. I'm stumped. > Seeing the same problem here that Ed saw. I am seeing one interesting twist that Ed didn't mention. If I start the telnet server on my F18 box with something like "server_args = -D report", I can login locally. If I try to log in from a different box, I get a "no route to host" message which is bogus since I can ping the F18 system or ssh to it. I messed with hosts.allow and hosts.deny but didn't see any change.
I don't see that. And, since you said iptables is stopped (I also tested that way), it is completely bogus.
Maybe the problem isn't in telnetd but in tcp wrappers instead.
A possibility. Not as easy to verify.....
On 01/29/2013 10:44 PM, Ed Greshko wrote:
I just installed the f17 rpm on the f18 system and it fails in the same way.
I never asked... Does telnetd work on F17 or would we have to go back further to find a working version?
Sorry, not looking for a replacement.
You don't need to apologize to me. It was just a suggestion. The older system you're trying to support almost certainly has rsh, and as far as I know, rsh is a simpler protocol, which makes it more secure than telnet in some respects and less prone to weird problems like this one.
Their management would probably prefer they used RHEL or CentOS anyway.
Which is probably sound advice. :)
On 01/30/2013 03:17 PM, Gordon Messmer wrote:
On 01/29/2013 10:44 PM, Ed Greshko wrote:
I just installed the f17 rpm on the f18 system and it fails in the same way.
I never asked... Does telnetd work on F17 or would we have to go back further to find a working version?
Yes, it works fine on F17.
Sorry, not looking for a replacement.
You don't need to apologize to me. It was just a suggestion. The older system you're trying to support almost certainly has rsh, and as far as I know, rsh is a simpler protocol, which makes it more secure than telnet in some respects and less prone to weird problems like this one.
They actually wrote a specialized telnet client on the Unix side which needs to be supported. The client side is automated with no human input. This is a hack written over 15 years ago when the server side was a mainframe running a proprietary OS. Instead of rewriting things to support new uses they continued down the path they knew.
Yes, we have PHB's in Taiwan too. :-(
Their management would probably prefer they used RHEL or CentOS anyway.
Which is probably sound advice. :)
:-)
On 01/30/2013 10:17 AM, jdow wrote:
Oh really! You mean Alan Cox was right about F18? Hm....
FWIW, the problem has been pinpointed to changes in /usr/bin/login. Taking login from F17 "fixes" the issue....
https://lkml.org/lkml/2013/1/15/641
-
Bruno Wolff III -
David G. Miller (aka DaveAtFraud) -
Ed Greshko -
Gordon Messmer -
James Hogarth -
jdow -
Matthew Miller -
Richard Sewill