Hi Folks, I've been meaning to raise this for some time, since I've never got to the bottom of what's causing it. Basically, I want *all* the machines on my local LAN to be able to telnet and ftp to each other. Between the older machines (Suse 5.2, Suse 7,2 and red Hat 9) there is no problem. But I've had a Debian Etch running now for about 18 months, and recently a Debian Lenny (provisional installation), and both of these deny attempts to telnet or ftp into them from the others ("connection refused"). However, I can of course telnet and ftp from either of these to any of the older machines. I have put ALL: ALL in the /etc/hosts.allow file (like in the older machines), but this does not seem to make any difference. I get the impression that access control has changed in some fundamental way, but I can't put my finger on it! Any suggestions gratefully welcomed! Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@manchester.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 09-Apr-09 Time: 22:15:47 ------------------------------ XFMail ------------------------------
On Thu, 09 Apr 2009 22:15:50 +0100 (BST) (Ted Harding) <Ted.Harding@manchester.ac.uk> allegedly wrote:
Basically, I want *all* the machines on my local LAN to be able to telnet and ftp to each other. Between the older machines (Suse 5.2, Suse 7,2 and red Hat 9) there is no problem.
Ted I hate to ask, but why? And particularly why telnet. Please consider using ssh and sftp - much, much more secure. OK you could argue that on a closed local network your are minimising your risk, but the fact that you run telnet and ftp daemons across such a wide range of machines by default is inherently insecure (passwords passed in clear for one thing). It is also a good idea to get out of the habit of using these old cleartext protocols.
But I've had a Debian Etch running now for about 18 months, and recently a Debian Lenny (provisional installation), and both of these deny attempts to telnet or ftp into them from the others ("connection refused"). However, I can of course telnet and ftp from either of these to any of the older machines.
You will almost certainly find that the debian systems are /not/ running telnet and ftp daemons. This is known as a /jolly good thing/. If you really want to be able to connect all of your machines each to the the other, then I suggest that you install openssh (client and server) on each machine. Use ssh in place of telnet and sftp in place of ftp. When you have the new daemons running satisfactorily on all machines, then stop the telnetd and ftpd daemons on the older machines. You will probably find that telnetd is run out of inetd.conf (or xinetd) whilst the ftp daemon may be running standalone on the old Suse machines and started by scripts in /etc/init.d or /etc/rc(n).d (I can't remember offhand).
I have put ALL: ALL in the /etc/hosts.allow file (like in the older machines), but this does not seem to make any difference.
The TCP wrappers files will only apply if the daemons are actually running (and configured to use the wrappers). Changes here will be irrelevant otherwise. Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
Hi, 2009/4/9 mick <mbm@rlogin.net>:
On Thu, 09 Apr 2009 22:15:50 +0100 (BST) (Ted Harding) <Ted.Harding@manchester.ac.uk> allegedly wrote:
Basically, I want *all* the machines on my local LAN to be able to telnet and ftp to each other. Between the older machines (Suse 5.2, Suse 7,2 and red Hat 9) there is no problem.
Why such old machines? Legacy software? For reference?
You will almost certainly find that the debian systems are /not/ running telnet and ftp daemons. This is known as a /jolly good thing/.
There's nothing badly wrong with FTP. You do not have to have telnet running for remote logins. You could perhaps have some strange data transfer using the telnet protocol. Eg, maybe transferring weather data from a weather sensor to some other processing system. With no logins, the fact that you run telnet does not matter [in the oft-touted security sense]. Now, if you are using telnet to do remote logins, I'd strongly suggest you move away from telnet. This may or may not be easier said than done.
You will probably find that telnetd is run out of inetd.conf (or xinetd) whilst the ftp daemon may be running standalone on the old Suse machines and started by scripts in /etc/init.d or /etc/rc(n).d (I can't remember offhand).
Yes, check /etc/inetd.conf or xinetd.conf and make sure the telnet part of the configuration is either not commented out, or is inserted (if it was not present there to begin with).
---------------------------------------------------------------------
The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this?
Douglas E Comer - Internetworking with TCP/IP Volume 1
http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
Do we really care about the massive signature? Thanks Srdjan
On Fri, 2009-04-10 at 00:14 +0100, Srdjan Todorovic wrote:
There's nothing badly wrong with FTP.
Apart from the plain text authentication. The out of band control channel making firewall/NAT traversal more difficult than it should be. Oh and no crc/error checking on the data stream. No other than there there is nothing badly wrong with it at all. There honestly is no reason whatsoever to use FTP now unless you are taking to some device that cannot support ssh/scp or TFTP boot of embedded devices or netbooting etc.
On Fri, 10 Apr 2009 00:14:24 +0100 Srdjan Todorovic <todorovic.s@googlemail.com> allegedly wrote:
Do we really care about the massive signature?
If it bothers, just delete the email. M --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------
On Thu, 2009-04-09 at 22:15 +0100, Ted.Harding@manchester.ac.uk wrote:
... But I've had a Debian Etch running now for about 18 months, and recently a Debian Lenny (provisional installation), and both of these deny attempts to telnet or ftp into them from the others ("connection refused"). However, I can of course telnet and ftp from either of these to any of the older machines.
I have put ALL: ALL in the /etc/hosts.allow file (like in the older machines), but this does not seem to make any difference.
I get the impression that access control has changed in some fundamental way, but I can't put my finger on it!
The message "connection refused" is easily misinterpreted as something to do with access control but it does not mean "access denied". It means the kernel refused to accept the TCP connection because there is nothing listening on the port specified by the client, i.e. because the server daemon is not running. These daemons do not run by default on Debian. If you want them you can install them and then configure them but openssh is more secure. Regards, Steve.
participants (6)
-
mick -
mick -
Srdjan Todorovic -
Steve Fosdick -
Ted.Harding＠manchester.ac.uk -
Wayne Stallwood