Controll

[jeffwass at MIT.EDU (Wass)]

Hi Lars,

	Here are some more questions.  How would the serial connection
work?  Does this involve the null-modem i've heard mention of before?

	About the ssh server, is this an accepted way to do things?
I wanted a physical connection, which would prevent networked attacks
(i hope???)  I didn't want to run ssh because then to listen for the
one computer on my LAN, I'd run a daemon which the rest of the internet
could access.  If it isn't obvious, my knowledge of this stuff is
sketchy at best.  My firewall is 192.168.0.1, and my primary desktop
is 192.168.0.2.  What's to stop someone else who also has their firewall
on a 192.168.0.x network from getting into mine?  The IP Masquerading
used these addresses as examples, so it would seem these are commonly
used.  or would someone else, working at their 192.168.0.x LAN, look
like they're coming straight from their firewall's IP address instead
of their 192.168.0.x address, and hence get filtered at my firewall?
	Sorry for my lack on understanding here.

	BTW, i'm running OpenSSL and OpenSSH on the firewall/desktops
now.  That was straightforward from the install instructions.  I can
successfully open an ssh client to athena.  But how much harder is it
to setup an ssh server?  As you can see, I'm a far cry from an admin,
but i'm constantly pushed to learn admin techniques (which is a good
thing, albeit somewhat time consuming).

	Thanks alot,

	- Wass


Lars Kellogg-Stedman hath scribed:
>> samba server, which is a box on the floor, plugged into the network, 
>> to answer telnet only to my desktop box. 
>> [...]
>> Are there other ways to do the admin?  I don't
>> need X, just command line stuff.  For instance, serial connections or
>> something similar?
>
>A serial connection will certainly work -- I've got an old VT220 terminal
>attached to my gateway box.  However, I use it only in emergencies (i.e.,
>if the network has died, or I've horked the system with an improperly
>configured kernel).
>
>My personal preference is to use ssh (the secure shell program), which lets
>one connect to a remote host using an encrypted channel so that one's
>password can't be sniffed over the wire.
>
>This means I can access my gateway box (and my internal network) remotely
>without worrying about nasties in the intervening networks.
>
>ssh has several other features that make it a good choice for remote access
>in general:
>
>  (1) ssh takes care of X11 forwarding automatically (and securely).
>      X connections are forwarded over your secure connection, so
>      (a) you don't have to set anything up manually, and (b) noone
>      is going to be able to sniff your X session.
>
>  (2) ssh can be used to provide generic port-forwarding services; that is,
>      you can set it up so that (for instance) connection to port 143 on
>      your gateway box will actually connection you to an IMAP server at
>      work -- at the same time encrypting all your traffic between the
>      gateway box and some other system at work.
>
>  (3) ssh has flexible authentication options.  Besides using passwords,
>      you can also use a public/private key mechanism that can be
>      especially convenient if you're making lots of connections and are
>      tired of having to type your password everytime.  Using the RSA
>      method, you can authenticate once to your local ssh software and then
>      connection to properly configured systems without having to
>      re-authenticate.
>
>There are ssh rpms for RedHat available from ftp.zedz.net.  You may also
>want to check out OpenSSH, based on code from the OpenBSD folks, at
>
>  http://violet.ibs.com.au/openssh/
>
>-- Lars
>
>
>-- 
>Lars Kellogg-Stedman <lars at larsshack.org> --> http://www.larsshack.org/
>
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).