Date: Mon, 9 Oct 2000 10:52:01 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.ORG> To: Doug Barton <DougB@gorean.org> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, Matt Dillon <dillon@earth.backplane.com>, Warner Losh <imp@village.org>, Jeroen Ruigrok van der Werven <jruigrok@via-net-works.nl>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/etc inetd.conf Message-ID: <Pine.NEB.3.96L.1001009103906.85778E-100000@fledge.watson.org> In-Reply-To: <39E15630.7B4A8FE6@gorean.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 8 Oct 2000, Doug Barton wrote: > Jordan Hubbard wrote: > > > Picture the following scenario: You're working at a data center > > setting up a dozen boxes in a rack and they are not as of yet on any > > public network, they're simply hooked to a hub/switch and can talk to > > one another and the windows laptop you have with you (since all the > > really colorful network sniff/trace software works under windows). > > You'd like to sit in the corner and use the laptop to log into each > > box to further configure it, and let's further say that your laptop > > just got Windows last week and is a pretty stock install. > > ERrr... the argument that telnet should be available from inetd > because a worker might be coming to a job with the wrong tools isn't > valid. A better argument to allow telnet is that sshd requires some > configuration, and telnet doesn't. > > However, isn't all of this moot in light of the planned > (existing?) options to sysinstall to specify exactly what to enable? My > personal feeling is that _everything_ should be off by default (in > /etc/defaults/rc.conf) and the user should pick specifically what to > enable. I'm finding the "telnet must die" argument a little hard to follow, personally. SSH is a poorly standardized protocol, with different variations and frequent incompatibilities. Several SSH clients don't support TISAuthentication, meaning they can't do complex challenge-response authentication, can't do multi-layer authentication, and so on. I'd like for us to wait to jump entirely on the SSH boat until there's a bit more interoperability and mature functionality: we still suffer from having SSH connections die when a high bandwidth X application is tunneled and exits, which is really a pretty poor failure mode. This is probably due to poorly written I/O routines in sshd. Also, SSH is not secure if you don't have the public key for the target host beforehand, and the public key is not generated during the install, rather, during the first multi-user boot, meaning that for a headless box, there is no way to get the key in advance, reducing you to a rather insecure mechanism subject to man-in-the-middle attacks. There's a lot of infrastructure that needs to go into place before SSH can be secure in the base install--we should be talking about that, and not how we're going to violently whack functionality out of the system in the name of security. In order to have SSH be useful for secure remote access immediately after install, the following needs to be the case: 1) The SSH keys must be generated during the sysinstall process, and must have adequate randomness. This means /dev/random must work during sysinstall, and be collecting entropy during the install process. 2) The SSH key fingerprints must be clearly displayed at some point during sysinstall so that the administrator can manually record the key fingerprints for manual verification following the install. This is a problem for entirely headless non-interactive installs, and may not be resolvable without another secure key submission mechanism during the install (i.e., sig(0)-protected DNSsec update, etc). Rather than whacking telnet, etc, from the base install, I agree a more specific configuration tool would be preferable. But until both that and a more reasonable SSH configuration mechanism exist, I would firmly object to disabling telnetd by default. I also object to the tool argument to a lesser degree: the majority of operating system platforms out there do not provide SSH support in the base system, meaning that if we disable telnet by default and don't have a way to enable it prior to the multi-user boot, we're substantially hampering interoperability. A further objection might be made that, last I checked, if you did a sysinstall based on a serial console, it was not possible to arrange for a login prompt to come up on the serial port without manual editing of /etc/ttys, which can only be done via network or real console login. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1001009103906.85778E-100000>