Re: Request for Comments: Getting OpenSSH to work with ssh.com and itself
From: Big Slick (bigslick_2k@hotmail.com)Date: 02/19/02
- Next message: Big Slick: "Re: Request for Comments: Getting OpenSSH to work with ssh.com and itself"
- Previous message: Richard E. Silverman: "Re: How do I port forward through 2 remote hosts?"
- In reply to: Richard E. Silverman: "Re: Request for Comments: Getting OpenSSH to work with ssh.com and itself"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: Big Slick <bigslick_2k@hotmail.com> Date: Mon, 18 Feb 2002 21:39:33 -0800
Thanks very much for your insightful comments. Since I am going for a
tutorial-style document as opposed to a complete reference. That being said
I did try to still add comments here and there and links to explanatory
text elsewhere. I also added a reference to your comments as a
non-distruptive citation. Hope that is OK.
Richard E. Silverman wrote:
>
>
================================================================================
>
> Several of the HTML links to other pages of your discussion are broken.
I think this should be fixed now. Let me know otherwise.
>
> --
>
> Your article starts by discussing "the password-less authentication
> mechanisms" of SSH, as if the technique discussing were the only
> way of doing this. There are various ways of doing it, using different
> SSH userauth methods, and the choice depends strongly on whether the
> intended use is interactive or batch. See:
>
> http://www.snailbook.com/faq/no-passphrase.auto.html
I changed this to "passwordless public key authentication", since the
"password-less" part seems to be the most visible benefit to the layman.
>
>
>
> spelling: "seemlessly" -> seamlessly
fixed.
>
> --
>
> The term "PKI," while technically applicable here, these days usually
> connotes an X.509 PKI, which you are not discussing. It may confuse
> people.
Since I'm going for tutorial-style flow, I think I'll probably sacrifice
completeness for flow. Hopefully this doesn't cause too much confusion but
I'll change it if it does.
>
> --
>
> (openssh, protocol 1)->(ssh.com, protocol 2)
> (ssh.com, protocol 2)->(openssh, protocol 1)
> (openssh, protocol 1)->(openssh, protocol 2)
> (openssh, protocol 2)->(openssh, protocol 1)
>
> Your choice of section titles for organizing this list of examples, is
> incorrect and confusing. All the titles involving mixed protocol versions
> do not make sense as written. SSH protocols 1 and 2 are incompatible;
> they cannot talk to one another. Various SSH software products are
> interoperable by sensing the protocol version and switching to the right
> one, but that is a different thing. And your titles and writing do not
> make it explicitly clear which protocol of the two you mention is actually
> the one you want to use, though one can usually infer it from context. In
> any event, half of what you appear to mean is not "protocol," but software
> version and/or configuration. For example, the first section really talks
> about "OpenSSH/1 -> the ssh.com SSH2 product with SSH-1 compatibility
> enabled." Etc.
Point taken. I added a note in the article:
"To be clear, the two protocol versions SSH1 and SSH2 do not interoperate,
but it is often the case that an SSH2 client or server can operate in SSH1
compatilibity mode, which means that it can talk to an SSH1 client/server.
For the rest of this article, I will assume that your SSH2 peer is able to
operate in SSH1-compatibility mode."
>
> Note the terminology at http://www.snailbook.com/terms.html; it is what I
> will use here, to avoid confusion.
>
> --
>
> (openssh, protocol 1)->(ssh.com, protocol 2)
>
> You do not mention that the server-side ssh.com installation must *also*
> have SSH1 installed alongside it -- a completely separate software package
> with a separate configuration.
I took this section out, becuase the PK Auth turns out not to work.
However, all my installations of ssh.com's SSH (2.4.0 and 3.0.0) seem to
interact with SSH1 out of the box.
>
> --
>
> You recommend using the "Keychain" script without discussing the security
> risk. Leaving your keys around inside an ssh-agent indefinitely means
> that if someone break root on your machine, they can easily use your keys
> with a single "setenv" command, or possible steal your keys by extracting
> them from the memory space of the running agent process. It's a much
> better idea to keep your keys loaded only for the duration of each login
> session. Someone may choose to take the risk, but they should at least
> know it's there.
I will mention this, but it's not just keychain that causes this problem.
Aside from keychain, people have written pages on adding a password prompt
on the startup of kde or gnome. I suppose that any time you leave your
password outside of your head, you will have the same problems.
>
> --
>
> (ssh.com, protocol 2)->(openssh, protocol 1)
>
> As noted above, this title does not make sense and should be rewritten; I
> assume what you mean is connecting an SSH2 client to an OpenSSH server,
> using protocol 1. This works in the version ssh.com version 3 release
> using the client-side SSH-1 internal compatibility code, and with earlier
> versions by fallback to executing ssh1. It works fine for me with no
> special effort.
The problem I've had here is that I haven't been able to convert the
ssh.com1 public key into a OpenSSH1 public key. Do you know what the right
utility is?
>
> --
>
> (openssh, protocol 1)->(openssh, protocol 2)
> (openssh, protocol 2)->(openssh, protocol 1)
>
> These are very confusing. Again, as noted above, the titles do not make
> sense. In both cases, you do not say explicitly which protocol version
> you want to use; both are possible, as OpenSSH implements both and you
> *mention* both. However, since you are generating RSA1 keys in both
> instances, apparently you mean to use protocol 1 in both. Anyway, the
> examples are identical, except for the comment output from the ssh-keygen
> program, which indicates that you're using an earlier version of OpenSSH
> on the client in the first example. I am left wondering, what is the
> point of having both these examples?
OK, I got rid of the section and just added a link.
>
> --
>
> "Therefore, all key pairs had to be encrypted with DSA."
>
> The keys are not "encrypted with DSA;" they *are* DSA keys. They are
> encrypted on disk using DES, via the user's passphrase.
fixed.
>
> --
>
> 'This is down with the "-i -f" options'
>
> * "down" -> done
fixed.
>
> * Also, note that earlier OpenSSH versions accomplished this via the
> -[xXy] options instead.
>
> --
>
> "Secondly, OpenSSH keeps all SSH2 public keys in the authorized_keys2 file
> as opposed to the authorized_keys file..."
>
> This was changed in OpenSSH 2.9; all server-side public keys are now kept
> in ~/.ssh/authorized_keys. "authorized_keys2", while it still works for
> now, is deprecated and will be removed at some point.
fixed.
>
> --
>
> You mention in one example that you were using SSH-2.4.0, and hence were
> restricted to using DSA keys in protocol 2. I would mention this at the
> top, since this affects other examples as well where it is not mentioned.
> Someone reading your article may read the top, then jump via link directly
> to an example where it is not discussed, and draw the wrong conclusion.
This is how I fixed it.
The top two links:
(openssh, protocol 1)->(ssh.com, protocol 2)
(ssh.com, protocol 2)->(openssh, protocol 1)
I haven't gotten working yet. Links 3 and 4:
(openssh, protocol 1)->(openssh, protocol 2)
(openssh, protocol 2)->(openssh, protocol 1)
don't have to worry about the DSA problem and Links 5 and 6
(ssh.com, protocol 2)->(openssh, protocol 2)
(openssh, protocol 2)->(ssh.com, protocol 2)
both talk about the DSA issue and the conversion issue. I'll move this to
the top when and if I ever fix links 1 and 2. I was hoping that each
section could more or less be self-contained so that someone could just
come to the page, select the relevant link and make their PKA work.
>
> --
>
> "I had two recent versions of ssh-keygen, only one of which was capable
> of import/export ssh.com public-keys. The incapable version was
> "OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090600f" (shipped
> with Red Hat 7.1)"
>
> As noted earlier, 2.5.2 *can* import ssh.com public keys; it simply uses a
> different set of options to do it. See the man page.
Fixed.
================================================================================
- Next message: Big Slick: "Re: Request for Comments: Getting OpenSSH to work with ssh.com and itself"
- Previous message: Richard E. Silverman: "Re: How do I port forward through 2 remote hosts?"
- In reply to: Richard E. Silverman: "Re: Request for Comments: Getting OpenSSH to work with ssh.com and itself"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
