This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin & openssh(d) & login without password


(I don't know _why_ I'm sitting at the keys on this glorious Saturday
morning, nor do I know why I'm replying to such a thread... Oh wait,
"I was a newbie once, too, and I remember what that was like." Yeah,
that's it! True, that was "back in the day," but I still remember...)

On Fri, 8 Oct 2004, lex ein wrote:
>
> On Tue, 5 Oct 2004 10:47:57 +0200, Corinna Vinschen
> <corinna-cygwin@cygwin.com> wrote:
> > On Oct  5 16:00, David Campbell wrote:
> >> I've read lots of web pages about how to set it up, and I believe I've
> >> followed them, eg http://bumblebee.lcs.mit.edu/ssh2/ (for openssh to
> >> openssh):
> >
> > WHY DON'T YOU READ THE OFFICIAL DOCUMENTATION INSTEAD? [caps mine]
> > OpenSSH comes with a lot of man pages.  Then there's
> > /usr/share/doc/Cygwin/openssh.README.
> > Then you could have used ssh-host-config and ssh-user-config for the
> > basic configuration.
>
> BECAUSE in the case of openssh(and others), the "official documentation"
> is of little use to a new user: information is not gathered, stored, or
> presented in a orderly, logical, or sensible hierarchical manner, is not
> meaningfully cross-referenced, and is not reasonably searchable.  There's
> just no usable thread to pull to unravel the mystery, either.


Well Lex, you are ABSOLUTELY RIGHT. First of all, though, you need to
realize that WJM. Yes, and not just the Cygwinners - and Cygwhiners - but
the whole Unix/Linux community!

As I see it, the single biggest problem for Unix/Linux acceptance by a
wider community is lack of an intuitive help strategy. The obvious reason
_why_ is because it's an evolution of _student_labor_ - students who, by
the way, may have been (were!) outstandingly bright but who had not yet
been out in the "real world." There _were_ great solutions to emulate,
such as Digital Equipment Corporation's VMS with it's stupendous 'help'
utility, but _students_ had nevery been out in the real world to encounter
such gems and therefore didn't have the experience of a competent system
to emulate for their Unix development work. ...Don't know what to do, nor
even where to start? Type help<return> and the system presents you with a
summary list of all the possible commands or groups of commands (so the
list isn't forever and a day long). Want more help? Type help
<item_from_list><return>, and this format can continue an arbitrary number
of levels and you can...  Bzzzzzzzzt!  Oh! That's the alarm clock going
off telling me it's time to wake up to where we are now - it's not 1986
any more.

Ssh configuration problems? RIGHT. It's VERY poorly described. VERY few
times have I found a good write up on it, though the cygwin setup package
for it is _superb._ I tend to only have to deal with it once in a very
long while - like years sometimes - and so a refresher is needed now and
then, especially when trying to get any of the varriants of SSH to talk to
one another. ... Did you know, for example, that there are THREE major
varriants of SSH? They're called OpenSSH, Commercial SSH and
non-Commercial SSH - but these are _just_ names as there are commercial
and non-commercial versions of ALL THREE! The two non-OpenSSH versions
talk well together but OpenSSH is the odd-man-out.

Oh, and responses on this list like this one:

> > Huh?  I have read /usr/share/doc/Cygwin/openssh.README, then I ran
> > sshd-config and ssh-config and it works for me.  I edited manually
> > the /etc/sshd_config file to disable password login and to enable
> > X forwarding.

are just downright rude and unhelpful. However, see note above wherein I
pointed out that WJM.

...Anyway, yes, the terminology used in describing ssh is _very_
challenging for the newbie, and can even be annoyingly obfuscated for the
experienced user! Unless you're willing to take this on yourself, however,
you've _got_ to deal with it because nobody's paying anybody to do a
better job and, speaking for myself only, I'm overworked and can't
volunteer to fix this for the community.

All that said, you've made your point. ...Here's a write up I did find
helpful out there:

http://www.netsys.com/cgi-bin/display_article.cgi?1254

And, in case it helps, below are some notes on setting up SSH in mixed
Open/non-Open ssh environments, and, in particular, including Cygwin.

Finally, I direct your attention to the bottom of the section below
regarding file transferr...

HTH,
Richard

-- 
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/
__________

The following is excerpted from notes between our engineers and our
documentation writers.
Enjoy, RT

-snip-

These notes are intended to help shorten the process of learning
how to set up ssh in a mixed (OpenSSH & non-OpenSSH) environment.

For new Science Tools customers with the typical scenario of Windows
clients running Cygwin (our preferred configuration), it's easiest to set
up users starting with keys generated on the Windows side. This is quite
useful for both Science Tools' SSH-based security for Java on Windows, and
for connecting users to Unix/Linux based servers which aren't running
OpenSSH.

>From a Windows system running Cygwin:

- It is easy to create TWO public-key/private-key pairs with Cygwin's
  OpenSSH, one RSA pair, and one DSA pair, and more complicated to
  configure more. Therefore, we recommend using an RSA pair for Science
  Tools' SSH-based security purposes which will be shared among users of
  Science Tools' products on Windows and a DSA pair for each user, to be
  kept private to their own personal use.

- From a Windows system running Cygwin (OpenSSH), run:

        ssh-keygen -t {rsa | dsa}

  to generate the keys.

  + Move the PRIVATE key to all user accounts that you want to be able to
    log into that account. This makes most sense for situations like the
    stsshsrvr account wherein many users will connect to the target
    account. (Note that the stsshsrvr account is "captive" in that it only
    runs our code when a connection occurrs - please see the
    Administrator's guide.)

  + Add the PUBLIC key to the authorized_keys2 file (which you must create
    yourself!) on all systems where you want a particular user to be able
    to log into using the matching private key.

- Still on Windows, from a users account, in their .ssh directory, run:

        ssh-keygen -e -f id_dsa.pub > new_public_keyfile.pub

  Now, move new_public_keyfile.pub (it can be named anything) to target
  accounts you want that user to be able to log into. It belongs in the
  appropriate .ssh2 (sometimes .ssh) directory. To enable use of the key,
  add an entry to the authorization file. You can do so with a command
  like this:

        echo "key new_public_keyfile.pub" >> ~user/.ssh2/authorization

- So far, so good, however, mixing and matching OpenSSH with non-OpenSSH
  is a disaster for file transferr! The reason is that while the transport
  protocol interoperates just fine, the copy program halves, one for
  either end, are actually quite incompatible and a "compatability mode"
  error is returned. This presents a problem. Users are urged to pick ONE
  SSH and stick to it.

  That said, there are usually workarounds that do well. For example, here
  at Science Tools, while we recommend (and use ourselves) Cygwin's
  OpenSSH for our products, many of our people preferr F-Secure as an ssh
  toolset as it gives a Windows-like interface even though Cygwin's
  OpenSSH works fine for most purposes. Rather than run two sshd
  servers, and have the conflict with port numbers that would entail, it
  happens that both OpenSSH and commercial and non-commercial SSH
  implementations can live as client installations side by side quite
  happily and that's what our users experience as they enjoy both the
  OpenSSH that comes with Cygwin and also the SSH tools provided by
  F-Secure.

  In particular, when it comes to file transferr, F-Secure provides
  Scp2.exe which works just fine in the scenario outlined here as
  it's not an OpenSSH. Therefore, you can have command-line based
  encrypted file transferr to either OpenSSH or non-OpenSSH servers by
  calling either scp or Scp2, as appropriate. Keys generated and managed
  as outlined above may easily be used by F-Secure by simply "importing"
  non-OpenSSH public keys using the F-Secure GUI interface.

-snip-


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]