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/
> > ******************************************************************************
> >
>
>
>
