Re: water, water everywhere, but not a drop to drink.
%% Kevin Stokes <linux@pieskysoft.com> writes:
ks> I wanted to remotely login from a Windows machine to my linux
ks> machine. So I wanted to install telnetd. Everyone said, 'shame
ks> on you, telnet is simply awful. You should be chained to the wall
ks> and whipped for wanting to use telnet! Use 'ssh' instead.'
As with all of the 'Net, don't believe everything you read. You should
understand the security issues involved with telnet. Your password will
be sent in cleartext over the network between your system and the remote
system. Anyone capable of intercepting that network traffic will be
able to steal your password, then log in to the target system (and any
other systems where you use the same password).
If you understand these risks and you're OK with them, telnet is fine.
In general, though, it's better to avoid insecure protocols like telnet:
get into the habit now to avoid trouble later.
Remember that you must have the telnet _server_ installed on Linux if
you want to log into the Linux box from another system; make sure the
telnetd package is installed (apt-get install telnetd).
ks> Well, ssh got installed along with everything when I installed
ks> linux. So I read the man pages for ssh. As is typical of the
ks> linux world, it is about 15 pages of utter gobbedly-gook. To be
ks> fair, man pages are not meant for newbies to learn linux from
ks> scratch.
Indeed. And, things like ssh are more complex than most commands.
Note there are a large number of web sites, etc. devoted to helping
Linux newbies. There are also books, both hardcopy and online
versions.
There's lots of resources, but most of it is on the net, not on your
local box.
ks> So I search until I find a HOWTO on ssh. This would be nice if it
ks> worked, but of course it doesn't. Everything seems to be
ks> different. Their suggestions fail. The paths are different.
ks> http://www.linuxdoc.org/LDP/LG/issue61/dellomodarme.html
This describes obtaining and installing ssh from scratch. It's also
talking about a completely different version of SSH; this is the
"commercial" SSH; Debian uses the free version created by the OpenBSD
folks, OpenSSH. In short, this HOWTO does not really apply well to
Debian, or even most other Linux distros. Why someone thinks it's a
good idea to explain how to install the proprietary version of SSH on a
Linux box in January, 2001 is beyond me. Ask the Linux Gazette what the
heck they're thinking.
In short, ignore this "HOWTO". See below.
As for directories; here's something to know:
When Debian packages are built to install on your system, they install
in the system directories (/usr/bin, etc.)
When you build packages yourself, they typically install in directories
specifically set aside for users to install software, under /usr/local.
This is A Good Thing, since it allows you to install your own copies of
software in a clean way, without disrupting the system versions.
ks> There is something that Linux needs much more than anything else,
ks> and that is a decent help system. We need something about 50
ks> times larger than the man pages. Something which always has an
ks> extensive chapter in simple layman language, and lots of examples
ks> with clear steps with *explanations*. And also a way to get to
ks> the more typically man page type stuff for the people who need
ks> that.
ks> Who is willing to create such a thing? Not me, I'm not a Linux
ks> devotee.
That's the problem. The people writing the program write documentation
that makes sense to them and to other people using it. This
documentation is naturally technical in nature. There's a certain
"critical mass" of knowledge you need to obtain before you can really
start understanding the documentation.
What's needed is for people like _you_ to help write "super newbie"
docs. We can't do it. We're not newbies. We don't know what newbies
need.
ks> But the bottom line is that the Windows Help system totally blows
ks> away all the confusing HOWTO's, man pages, or archived email
ks> searches.
See, here's a prime example of the differences in our perspective.
The Windows Help system _sucks_ huge boulders through coffee stirrers.
It totally blows chunks.
It has _NOTHING_ in it that I could ever possibly need to be told. I
ask it how to do something and it never tells me, it just gives me some
generic mush, if anything, that's totally obvious in the first place.
I wanted to know how to remap my CAPSLOCK key to be a control key. It
didn't know. I wanted to know how to keep my CDROM drive from spinning
down so quickly. It didn't know. I wanted to find out a hundred things
like that. Windows Help was utterly and completely useless.
Sure, it was great if I wanted to know that C-x was the keyboard
shortcut for Cut and C-v was the shortcut for Paste. Whoop-de-doo.
:)
ks> Anyway... Does anybody know what steps I need to do in order make
ks> ssh work so I can log in remotely? I wanted to try to use Tera
ks> Term Pro with the SSH extenstion to log onto my Linux machine from
ks> a Windows machine on the local network.
ks> Right now if I type:
ks> ssh -v -l root rocky
Here's the thing.
You can't login remotely as root, by default, over ssh: the ssh setup
disallows this (as with everything in UNIX, this is configurable if you
really want to do it--it's a bad idea so it's disabled initially).
You don't want to work as root, at all, ever, anytime, anywhere,
anyplace. Even for testing. _Especially_ for testing. Use root only
when you must do root operations, then run screaming into the bushes
again immediately after you've done that operation.
Go now to your system and create yourself a user account all of your
own. Debian install will have highly recommended that you do so. If
you did not take its advice, then do this (say you want user "kevin"):
Be root:
# groupadd kevin
# useradd -g kevin -m kevin
# passwd kevin
and give yourself a password. Now, log out from root and log in as
"kevin".
Here's the second thing: there are _two_ ways to use SSH. One is to
authenticate using normal password methods; in this method you have to
type a password and SSH just encrypts the transport. I actually have
never once used this, but I think you don't need to do anything special
(like make keys with ssh-keygen, etc.) to use it.
ks> I get this error message about authenticity not being established.
ks> I made a 'indentification' and an authorization file in the ~/.ssh
ks> directory along with the keys created by ssh-keygen, but I really
ks> don't know what I'm doing.
To use RSA (public/private) key authentication, do this:
1) When logged in as yourself, run ssh-keygen. This will give you a new
public/private key pair, and put them in the right spot (~/.ssh).
2) The _server_, or remote, system must have your _PUBLIC_ key in the
~/.ssh/authorized_keys file, one key per line. Anyone trying to log
into the system who has a private key that matches any of these
public keys will be granted access.
The private part of the key you just created is ~/.ssh/identity. The
public part of the key is ~/.ssh/identity.pub.
Since this is your first key, you can just copy the public one to
authorized_keys:
$ cp ~/.ssh/identity.pub ~/.ssh/authorized_keys
If you have more than one you have to append them, of course.
3) To test it locally, you can now ssh to your own system:
$ ssh -l kevin localhost
If that doesn't work, report back as to exactly what happens (what
errors you see, etc.) Also you can turn on verbose mode (add the -v
option) to maybe see more information.
If that does work, now you need to give your private key to the Windows
SSH client. I'm not familiar with it, so I can't really help, but you
need to get the contents of the ~/.ssh/identity file installed in your
Windows client somewhere.
Be careful! That private key is like your password; anyone who gets a
copy can get into your system. It's a good idea to sign the key with a
passphrase when ssh-keygen asks for one: then people not only need the
private key but they also need your passphrase. This is more secure
because the passphrase is used only to unlock the key locally; neither
the passphrase _NOR_ the key itself are ever transmitted over the
network.
Public/private key cryptography is not the most straightforward thing in
the world, unfortunately.
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@baynetworks.com> HASMAT--HA Software Methods & Tools
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Reply to: