On Thu, Feb 10, 2000 at 08:38:41PM +0100, Gustav Schaffter wrote:
| > Beware, this is a bit long!
| > I have downloaded and installed openssh (and openssl as required by
| > openssh). It is my intention to completely remove the r-services
| > (rlogin, etc.).
Very cool.
| > As such, I believe that I should go for the third alternative within the
| > ssh documentation; To let all users create their own key pair. (This
| > requires all users to be 'aware' which I naively thought would not be
| > necessary with the ssh solution. Or am I missing something?)
Well, with ssh (F-Secure's one) you can do something like the
r-services' rhosts scheme (a bit more securely, because you make
keypairs for your trusted machines). But the user-aware personal
keypair scheme is better and more flexible, though you're right; the
users must be aware of it.
| > For instance, a user '[EMAIL PROTECTED]' creates a private/public key
| > pair. The public key is now given to '[EMAIL PROTECTED]' so that the user
| > can securely ssh login from pcA to pcB.
Yes.
| > Now pcB uses this public key, stored in pcB, to encrypt a random number
| > and send this back to pcA as a challenge. pcA is the only one having the
| > private key and the only one that can decrypt the challenge and send it
| > back to pcB for authentication.
| > Question: Doesn't this imply that the public key from pcA must be given
| > to pcB on a secure channel?
No. That's why public key cryptography is so neat; being a public key,
you don't need to protect it. All the challenge proves is that pcB
really is talking to a@pcA.
| > AFAIK, there is no tool to verify key fingerprints as we do before we
| > trust a public pgp/gpg key. Or am I missing something here?
Ah, now I see your point. The key must be placed on pcB in a trusted
fashion in that pcB must be confident it's putting in the right public
key. Yes.
| > And how does the host keys fit in? After installation of the rpms on two
| > PCs at home, I found the private and public host keys already generated
| > in /etc/ssh on both machines. Correct?
I'd expect so. It's a standard and necessary part of the install. The
host keys protect you from man-in-the-middle or spoofing attacks by
letting you verify that you're connecting to the machine you asked to
connect to. You still have to obtain the public keys of machines
you've never used before. Usually you accept it on the first
connection, which is a lose if that first connection is spoofed by an
attacker. If that's a real issue for you then you will need to use
another method (like trudging to the machine with a floppy disc or
suchlike).
However, once you have the public host key, that's then checked on
subsequent connections and you'll be warned if it doesn't match.
Usually this reflects a reinstall but it can also mean you're being
spoofed.
| > So, I took the /etc/ssh/ssh_host_key.pub from pcB and stored it as
| > /etc/ssh_known_hosts in pcA. (The /etc/ssh_known_hosts file didn't exist
| > before in pcA.)
| > Then I tried as an ordinary user at pcA to 'ssh -l user pcB' to login as
| > user 'user' on pcB. The first response is that ssh tells me that "the
| > autenticity of pcB can't be established, key fingerprint is bla,bla. Do
| > you want to continue?".
Does the name of pcB in /etc/ssh_known_hosts match the name on the
command line of your sh command? Just guessing here. I'm running
F-Secure ssh instead of openssh at present and so maybe something is
going on here I don't know about.
| > Again, what tools do I have as root to verify the autenticity of the
| > public host key from pcB? And as an ordinary user?
The public key files should be publicly readable (hmm, have you checked
this on your /etc/ssh_known_hosts file?); you shouldn't need to be root
to do these checks (obviously you want to be root to update the
/etc/ssh_known_hosts file!) The /etc/ssh_known_hosts is generally for
your intranet host keys; external boxes tend to be per-person and go in
the personal known_hosts file, which serves the same purpose per user.
--
Cameron Simpson, DoD#743 [EMAIL PROTECTED] http://www.zip.com.au/~cs/
It is idle to talk always of the alternative of reason and faith.
Reason itself is a matter of faith.
- James Sledd <[EMAIL PROTECTED]>
--
To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe"
as the Subject.
