You can also use the twist or banners feature on tcp wrappers (if enabled)
to display a message when connecting via telnet or rsh. The message can
tell them to use ssh instead of the insecure method.
I have it set up to tell the user to use ssh instead of the insecure
methods. Some caveats: rsh banners will not display the first character
and not display more than one line, and the banners will interfere with
programs and automated scripts that use rsh.
yuji
----
On Mon, 18 Oct 1999, Phil Hurvitz wrote:
> Right, I figured this one out after thinking for a little while. Thanks
> to Chris and the general group for consistent and effective help!
>
> -P.
>
> ******************************************************************************
> Phil Hurvitz, MFR | GIS Specialist | College of Forest Resources | 355 Bloedel
> Box 352100 | University of Washington, Seattle, Washington 98195-2100, USA
> tel: 206.685.8179 | FAX: 206.685.3091 | e-mail: [EMAIL PROTECTED]
> WWW: http://lobo.cfr.washington.edu/phurvitz/
> ******************************************************************************
>
>
> On Mon, 18 Oct 1999, C. Vandersip wrote:
>
> > Phil,
> >
> > The scenarios you suggest aren't possible. Each client requires it's own
> > daemon in order to work (i.e., telnet requires making a connection to
> > in.telnetd, rlogin requires connecting to in.rlogind, etc.). You can't
> > route incoming telnet or other requests to sshd. sshd looks for ssh client
> > requests only. It doesn't know what to do with a telnet or rlogin request.
> > There's no similar "handshaking" and, more importantly, there's NO
> > encryption (!!) in those services.
> >
> > By limiting access in the hosts.allow and hosts.deny files you can block
> > unwanted service connections without the scenarios you describe. The
> > strictest way to do this is to deny access to all wrapped services
> > (ALL:ALL in /etc/hosts.deny) and use /etc/hosts.allow to allow trusted
> > hosts to use particular wrapped services:
> >
> > Example /etc/hosts.allow ---
> >
> > #Network service permissions are granted to the following remote hosts:
> > #
> > # ssh
> > sshd2: trusted1.host.com,trusted2.host.com
> > #
> > # telnet
> > in.telnetd: trusted1.host.com (or blank if you don't allow this service)
> > #
> > # rlogin
> > in.rlogind: trusted1.host.com (or blank if you don't allow this service)
> > #
> > # rsh
> > in.rshd: trusted1.host.com (or blank if you don't allow this service)
> > #
> > # ftp
> > in.ftpd: trusted1.host.com (or blank if you don't allow this service)
> > #
> > # finger
> > in.fingerd: trusted1.host.com (or blank if you don't allow this
> > service)
> >
> > These are Solaris daemon names. Modify for your OS.
> >
> >
> > So, to correct your mischief :), restore your original inetd.conf so that
> > clients point to the right daemons. For example, for telnet requests to
> > work, the line in inetd.conf should read:
> >
> > telnet stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.telnetd
> >
> > so that it finds the right daemon. Also make sure you restore the orginal
> > port settings (e.g., 22 for ssh, 23 for telnet, 21 for ftp, etc.) in
> > /etc/services.
> >
> >
> > Now...and this can be the hardest part...convince those whom you would
> > like to allow to connect to your machine to install ssh on their machine
> > (or SecureCRT or F-Secure for PC/Mac users). :>
> >
> >
> > BTW, the only "exception" (of sorts) to this rerouting you describe is
> > that the ssh client can be setup to fall back to rsh (compile with the
> > --with-rsh=/usr/bin/rsh option in configure) if the remote computer you
> > are connecting to does not have the sshd daemon running. Not really the
> > same thing as you describe, but a useful - though not secure - option
> > nonetheless.
> >
> >
> > Regards,
> >
> > Chris
> >
> >
> > ###############################################################
> > # Chris Vandersip #
> > # Computer Research Specialist/Dept. Sysadmin #
> > # Rm. 024, Dept. of Meteorology, Florida State University #
> > # [EMAIL PROTECTED] (850)644-2522 #
> > ###############################################################
> >
> > On Mon, 18 Oct 1999, Phil Hurvitz wrote:
> >
> > > Alright, now that I've got ssh using tcp wrappers, here's what I want to
> > > do:
> > >
> > > Incoming telnet, rsh, rlogin, etc. should be forwarded to ssh rather than
> > > the old-style connections
> > >
> > > ----
> > > scenario 1:
> > >
> > > /etc/inetd.conf:
> > > telnet stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sshd -iA
> > > login stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/sshd -i
> > >
> > > to make telnet and login to use ssh through tcp wrapper
> > >
> > > /etc/services:
> > > telnet 22/tcp
> > > login 22/tcp
> > >
> > > to tell inetd to route incoming login & telnet to the ssh port
> > >
> > > (kill -HUP inetd.pid)
> > >
> > > But then I get this:
> > >
> > > myclient:133# telnet myserver
> > > Trying 128........ #my edit here
> > > telnet: Unable to connect to remote host: Connection refused
> > >
> > > ------
> > > scenario 2:
> > >
> > > I use the standard tcp ports in /etc/services for telnet and login, and
> > > still get Connection refused, which is not surprising.
> > >
> > > ------
> > > scenario 3:
> > >
> > > just like scenario 1, but with hosts.allow edited to allow myhost to use
> > > telnet.
> > >
> > >
> > > I have a feeling there is something simple I am overlooking. I'll SUM....
> > >
> > > -P.
> > >
> > > ******************************************************************************
> > > Phil Hurvitz, MFR | GIS Specialist | College of Forest Resources | 355 Bloedel
> > > Box 352100 | University of Washington, Seattle, Washington 98195-2100, USA
> > > tel: 206.685.8179 | FAX: 206.685.3091 | e-mail: [EMAIL PROTECTED]
> > > WWW: http://lobo.cfr.washington.edu/phurvitz/
> > > ******************************************************************************
> > >
> >
> >
> >
>
>
>
Yuji Shinozaki Systems Administrator
[EMAIL PROTECTED] Dept of Physics and Astronomy
http://www.physics.unc.edu Univ. of North Carolina - CH
(919)962-7214 (voice) CB 3255 Philips Hall
(919)962-0480 (fax) Chapel Hill, NC 27599
