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