Re: Openssh for Windows - openssh

This is a discussion on Re: Openssh for Windows - openssh ; You might want to consider to use Microsoft's Services For Unix. A nice OpenSSH implementation (client and server, including public-key authentications!) is provided by Interopsystems. Some links: http://technet.microsoft.com/en-us/i.../bb380242.aspx http://www.interopsystems.com/community/default.htm http://debian-interix.net/ The Debian page provides a highly recommended list of patches ...

+ Reply to Thread
Results 1 to 13 of 13

Thread: Re: Openssh for Windows

  1. Re: Openssh for Windows

    You might want to consider to use Microsoft's Services For Unix.
    A nice OpenSSH implementation (client and server, including
    public-key authentications!) is provided by Interopsystems. Some
    links:

    http://technet.microsoft.com/en-us/i.../bb380242.aspx
    http://www.interopsystems.com/community/default.htm
    http://debian-interix.net/

    The Debian page provides a highly recommended list of patches
    to install.


    Good luck

    Harri

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: Openssh for Windows

    On Jul 28 16:33, Harald Dunkel wrote:
    > You might want to consider to use Microsoft's Services For Unix.
    > A nice OpenSSH implementation (client and server, including
    > public-key authentications!) is provided by Interopsystems. Some


    Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Openssh for Windows



    Corinna Vinschen wrote:
    > On Jul 28 16:33, Harald Dunkel wrote:
    >> You might want to consider to use Microsoft's Services For Unix.
    >> A nice OpenSSH implementation (client and server, including
    >> public-key authentications!) is provided by Interopsystems. Some

    >
    > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.


    Cygwin is probably your best solution for OpenSSH under Windows.
    However, if you want a more minimal solution then you may want to look
    at CopSSH http://www.itefix.no/i2/node/27. Its a port of OpenSSH which
    uses a minimal Cygwin environment in straightforward installer package.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: Openssh for Windows

    Corinna Vinschen wrote:
    > On Jul 28 16:33, Harald Dunkel wrote:
    >> You might want to consider to use Microsoft's Services For Unix.
    >> A nice OpenSSH implementation (client and server, including
    >> public-key authentications!) is provided by Interopsystems. Some

    >
    > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
    >


    Surely I don't want to goof on Cygwin, but you mean you can
    login via ssh on a remote Windows XP host without being asked
    for a password? Within an LDAP environment, including your
    home directory on a remote network drive?

    Maybe I missed some trick hidden too deep in the documentation,
    but I never made this work with Cygwin's ssh (in 2006). AFAICR
    sshd was not running with the appropriate rights to read the
    user's .ssh directory on a remote share, and there was no "regpwd"
    tool as there is for Interix.


    Regards

    Harri
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: Openssh for Windows

    On Jul 29 09:12, Harald Dunkel wrote:
    > Corinna Vinschen wrote:
    > > On Jul 28 16:33, Harald Dunkel wrote:
    > >> You might want to consider to use Microsoft's Services For Unix.
    > >> A nice OpenSSH implementation (client and server, including
    > >> public-key authentications!) is provided by Interopsystems. Some

    > >
    > > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
    > >

    >
    > Surely I don't want to goof on Cygwin, but you mean you can
    > login via ssh on a remote Windows XP host without being asked
    > for a password? Within an LDAP environment, including your
    > home directory on a remote network drive?
    >
    > Maybe I missed some trick hidden too deep in the documentation,
    > but I never made this work with Cygwin's ssh (in 2006). AFAICR
    > sshd was not running with the appropriate rights to read the
    > user's .ssh directory on a remote share, and there was no "regpwd"
    > tool as there is for Interix.


    You can use password-less authentication and Cygwin will create
    a user token for your user. This user token has no credentials for
    network access because you only get that when using password
    authentication. The result is that you only get your remote home dir
    after logging in by using `net use share /user:domain\user password',
    thus explicitely authenticating against the sharing server.

    The method Interix uses is to store a copy of the user's password in the
    registry in a two-way encrypted fashion, which is then used whenever
    Interix needs to impersonate a user. That means, the pubkey
    authentication is used in OpenSSH, but the actual authentication against
    the OS is using password authentication. The result is that you get a
    user token which includes the network credentials to access your home
    dir automatically.

    The advantage of the Interix method is that the user token is a password
    authenticated token with network credentials. The downside is that
    there's a two-way encrypted copy of your password somewhere in an
    undocumented place in the registry, using an undocumented two-way
    encryption.


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: Openssh for Windows

    On Jul 29 10:17, Corinna Vinschen wrote:
    > On Jul 29 09:12, Harald Dunkel wrote:
    > > Corinna Vinschen wrote:
    > > > On Jul 28 16:33, Harald Dunkel wrote:
    > > >> You might want to consider to use Microsoft's Services For Unix.
    > > >> A nice OpenSSH implementation (client and server, including
    > > >> public-key authentications!) is provided by Interopsystems. Some
    > > >
    > > > Cygwin supports pubkey since at least OpenSSH 2.1.0p3, back in 2000.
    > > >

    > >
    > > Surely I don't want to goof on Cygwin, but you mean you can
    > > login via ssh on a remote Windows XP host without being asked
    > > for a password? Within an LDAP environment, including your
    > > home directory on a remote network drive?
    > >
    > > Maybe I missed some trick hidden too deep in the documentation,
    > > but I never made this work with Cygwin's ssh (in 2006). AFAICR
    > > sshd was not running with the appropriate rights to read the
    > > user's .ssh directory on a remote share, and there was no "regpwd"
    > > tool as there is for Interix.

    >
    > You can use password-less authentication and Cygwin will create
    > a user token for your user. This user token has no credentials for
    > network access because you only get that when using password
    > authentication. The result is that you only get your remote home dir
    > after logging in by using `net use share /user:domain\user password',
    > thus explicitely authenticating against the sharing server.


    Btw., if you only need pubkey authentication for a single account, you
    can do that in Cygwin by running sshd under that account. In this case,
    there's no actual user context switch, just the authentication part.
    This has an obvious advantage. Since sshd is already running as that
    user, the user token has all credentials for accessing the required
    network drives. And, you don't have to run sshd under a privileged
    account if you don't feel confortable to do that on Windows.


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  7. Re: Openssh for Windows

    Corinna Vinschen wrote:
    >
    > You can use password-less authentication and Cygwin will create
    > a user token for your user. This user token has no credentials for
    > network access because you only get that when using password
    > authentication. The result is that you only get your remote home dir
    > after logging in by using `net use share /user:domain\user password',
    > thus explicitely authenticating against the sharing server.
    >


    If I got you correctly then this means that Cygwin's sshd doesn't
    have permission to access my .ssh for authentication, if it is on
    a remote disk. Doesn't this mean that pubkey simply doesn't work
    in this case?

    > The method Interix uses is to store a copy of the user's password in the
    > registry in a two-way encrypted fashion, which is then used whenever
    > Interix needs to impersonate a user. That means, the pubkey
    > authentication is used in OpenSSH, but the actual authentication against
    > the OS is using password authentication. The result is that you get a
    > user token which includes the network credentials to access your home
    > dir automatically.
    >
    > The advantage of the Interix method is that the user token is a password
    > authenticated token with network credentials. The downside is that
    > there's a two-way encrypted copy of your password somewhere in an
    > undocumented place in the registry, using an undocumented two-way
    > encryption.
    >


    I am surely not an advocate for Windows, but the Unix procedure is
    pretty rude, too: sshd is running with root permission. Since the
    NFS partition containing my $HOME might be mounted without giving
    root the right to read all files it likes (no_root_squash), sshd has
    to break into my account (via seteuid(1), I would guess) to read my
    ..ssh directory.

    In other words, sshd on Unix doesn't need an encrypted copy of my
    password to generate some network credentials (as Interix' sshd
    does). It bypasses all security means by brute force.

    I can live with both. But I have to say that Cygwin's sshd doesn't
    match my needs.


    Regards

    Harri

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  8. Re: Openssh for Windows

    On Jul 29 11:02, Harald Dunkel wrote:
    > Corinna Vinschen wrote:
    > >
    > > You can use password-less authentication and Cygwin will create
    > > a user token for your user. This user token has no credentials for
    > > network access because you only get that when using password
    > > authentication. The result is that you only get your remote home dir
    > > after logging in by using `net use share /user:domain\user password',
    > > thus explicitely authenticating against the sharing server.
    > >

    >
    > If I got you correctly then this means that Cygwin's sshd doesn't
    > have permission to access my .ssh for authentication, if it is on
    > a remote disk. Doesn't this mean that pubkey simply doesn't work
    > in this case?


    Basically yes. The usual workaround is to define a local home dir
    which contains the .ssh dir and to attach to the network drive after
    authentication.

    However, if sshd is running from a domain account which has access
    to the network drives, and if /etc/passwd has the homedirs mentioned
    as UNC paths, you can get this working transparently. It just requires
    a bit of administration. The user still has no network credentials, of
    course, so the explicit `net use' is still required.

    Btw., in the next major Cygwin release you can use NFS shares instead of
    SMB shares for your home dir (together with Microsoft's NFS client). As
    long as you use UNC paths, rather than drive letters, you can access
    them just fine from your user account without having to call `net use'.
    Provided you installed the name mapping service correctly.

    > > The advantage of the Interix method is that the user token is a password
    > > authenticated token with network credentials. The downside is that
    > > there's a two-way encrypted copy of your password somewhere in an
    > > undocumented place in the registry, using an undocumented two-way
    > > encryption.

    >
    > I am surely not an advocate for Windows, but the Unix procedure is
    > pretty rude, too: sshd is running with root permission. Since the
    > NFS partition containing my $HOME might be mounted without giving
    > root the right to read all files it likes (no_root_squash), sshd has
    > to break into my account (via seteuid(1), I would guess) to read my
    > .ssh directory.
    >
    > In other words, sshd on Unix doesn't need an encrypted copy of my
    > password to generate some network credentials (as Interix' sshd
    > does). It bypasses all security means by brute force.


    As Interix does. And IMHO even worse. Interix has access to your
    cleartext(!) password. You entered it when calling regpwd, then it gets
    encrypted, but Interix knows the key to fetch it back in cleartext
    whenever it needs it to create a user token on your behalf.

    Actually, if we wanted to, we could easily do the same. But I'm still
    feeling rather uncomfortable with the idea to have two-way encrypted
    password stored somewhere in the system.

    > I can live with both. But I have to say that Cygwin's sshd doesn't
    > match my needs.


    That's ok. That doesn't mean that Cygwin isn't useful for other people


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  9. Re: Openssh for Windows

    Circa 2008-07-29 06:08 dixit Corinna Vinschen:

    : > > The advantage of the Interix method is that the user token is a password
    : > > authenticated token with network credentials. The downside is that
    : > > there's a two-way encrypted copy of your password somewhere in an
    : > > undocumented place in the registry, using an undocumented two-way
    : > > encryption.

    [...]

    : Actually, if we wanted to, we could easily do the same. But I'm still
    : feeling rather uncomfortable with the idea to have two-way encrypted
    : password stored somewhere in the system.

    You could encrypt the user's password using the user's SSH public key.
    Then the private key could be used to both authenticate and decrypt the
    password. It's a bit cumbersome if there are more than a few keypairs
    used to access the account, but ... just a thought.

    --
    jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
    (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ )
    (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA )
    +----------------------------------------------------------------------+
    |[L]iberty, as we all know, cannot flourish in a country that is perma-|
    | nently on a war footing, or even a near-war footing. --Aldous Huxley|
    +----------------------------------------------------------------------+
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  10. Re: Openssh for Windows

    On Jul 29 14:00, Jim Knoble wrote:
    > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
    > : Actually, if we wanted to, we could easily do the same. But I'm still
    > : feeling rather uncomfortable with the idea to have two-way encrypted
    > : password stored somewhere in the system.
    >
    > You could encrypt the user's password using the user's SSH public key.
    > Then the private key could be used to both authenticate and decrypt the
    > password. It's a bit cumbersome if there are more than a few keypairs
    > used to access the account, but ... just a thought.


    That's an interesting idea but the problem is that the user context
    change is generic code buried within the seteuid call. It has to work
    with all sorts of applications changing the user context, not just with
    sshd. Therefore, a generic solution is required.

    I'm not overly encryption savvy. Is it at all possible to store a
    two-way encrypted password in a safe way, using a known encryption
    mechanism, storing it in a known location? Even if another key is used
    on every machine?


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  11. Re: Openssh for Windows

    Corinna Vinschen wrote:
    > On Jul 29 14:00, Jim Knoble wrote:
    >> Circa 2008-07-29 06:08 dixit Corinna Vinschen:
    >> : Actually, if we wanted to, we could easily do the same. But I'm still
    >> : feeling rather uncomfortable with the idea to have two-way encrypted
    >> : password stored somewhere in the system.
    >>
    >> You could encrypt the user's password using the user's SSH public key.
    >> Then the private key could be used to both authenticate and decrypt the
    >> password. It's a bit cumbersome if there are more than a few keypairs
    >> used to access the account, but ... just a thought.

    >
    > That's an interesting idea but the problem is that the user context
    > change is generic code buried within the seteuid call. It has to work
    > with all sorts of applications changing the user context, not just with
    > sshd. Therefore, a generic solution is required.
    >
    > I'm not overly encryption savvy. Is it at all possible to store a
    > two-way encrypted password in a safe way, using a known encryption
    > mechanism, storing it in a known location? Even if another key is used
    > on every machine?


    I don't think it's feasible from a protocol perspective; for ssh v2 the
    server never has access to the corresponding private key, only a chunk
    of data provided by the client that's signed with the private key (said
    chunk of data containing amongst other things a session id and the user
    name).

    --
    Darren Tucker (dtucker at zip.com.au)
    GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
    usually comes from bad judgement.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  12. Re: Openssh for Windows

    Circa 2008-07-30 04:58 dixit Corinna Vinschen:

    : On Jul 29 14:00, Jim Knoble wrote:
    : > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
    : > : [...] But I'm still feeling rather uncomfortable with the idea to
    : > : have two-way encrypted password stored somewhere in the system.
    : >
    : > You could encrypt the user's password using the user's SSH public key.
    : > Then the private key could be used to both authenticate and decrypt the
    : > password. It's a bit cumbersome if there are more than a few keypairs
    : > used to access the account, but ... just a thought.
    :
    : That's an interesting idea but the problem is that the user context
    : change is generic code buried within the seteuid call. It has to work
    : with all sorts of applications changing the user context, not just with
    : sshd. Therefore, a generic solution is required.

    Hmm. That definitely sounds more complex than one would want it to be.
    The generic solution really sounds like Kerberos.

    : I'm not overly encryption savvy. Is it at all possible to store a
    : two-way encrypted password in a safe way, using a known encryption
    : mechanism, storing it in a known location? Even if another key is
    : used on every machine?

    It depends on what risks are acceptable to you. Unless the user enters
    the encryption key itself or a passphrase for the key, then the
    encryption key must be stored in what is effectively plaintext, either
    in permanent (disk) or volatile (RAM) storage. Thus, an attacker who
    gains sufficiently privileged access to disk or RAM (e.g., through a
    rootkit) would effectively gain access to the plaintext password as
    well.

    That's why i suggested using the SSH private key, as it can be made to
    depend on a private passphrase stored separately from the encrypted
    password. Darren Tucker's response that sshd doesn't really know the
    private key makes that more difficult; sshd would have to ask the client
    to decrypt the encrypted password and send the plaintext password back
    to the server. That sounds overly complex.

    To make it simpler, the server could ask the user for the encryption key
    or a passphrase for the encryption key, as part of a two-step
    authentication method. But that's effectively the same as just asking
    the user for the actual password, which is what happens now with the
    "net use" command....

    --
    jim knoble | jmknoble@pobox.com | http://www.pobox.com/~jmknoble/
    (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ )
    (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA )
    +----------------------------------------------------------------------+
    |[L]iberty, as we all know, cannot flourish in a country that is perma-|
    | nently on a war footing, or even a near-war footing. --Aldous Huxley|
    +----------------------------------------------------------------------+
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  13. Re: Openssh for Windows

    On Jul 30 15:25, Jim Knoble wrote:
    > Circa 2008-07-30 04:58 dixit Corinna Vinschen:
    >
    > : On Jul 29 14:00, Jim Knoble wrote:
    > : > Circa 2008-07-29 06:08 dixit Corinna Vinschen:
    > : > : [...] But I'm still feeling rather uncomfortable with the idea to
    > : > : have two-way encrypted password stored somewhere in the system.
    > : >
    > : > You could encrypt the user's password using the user's SSH public key.
    > : > Then the private key could be used to both authenticate and decrypt the
    > : > password. It's a bit cumbersome if there are more than a few keypairs
    > : > used to access the account, but ... just a thought.
    > :
    > : That's an interesting idea but the problem is that the user context
    > : change is generic code buried within the seteuid call. It has to work
    > : with all sorts of applications changing the user context, not just with
    > : sshd. Therefore, a generic solution is required.
    >
    > Hmm. That definitely sounds more complex than one would want it to be.
    > The generic solution really sounds like Kerberos.


    Still needs a supported user authentication method, password or smart
    card. It's way over my head to write a Windows Kerberos authentication
    plugin.

    > : I'm not overly encryption savvy. Is it at all possible to store a
    > : two-way encrypted password in a safe way, using a known encryption
    > : mechanism, storing it in a known location? Even if another key is
    > : used on every machine?
    >
    > It depends on what risks are acceptable to you. Unless the user enters
    > the encryption key itself or a passphrase for the key, then the
    > encryption key must be stored in what is effectively plaintext, either
    > in permanent (disk) or volatile (RAM) storage. Thus, an attacker who
    > gains sufficiently privileged access to disk or RAM (e.g., through a
    > rootkit) would effectively gain access to the plaintext password as
    > well.


    It would have to be in permanent storage, as Interix does (registry).
    In contrast to Interix, everybody would know from source where the keys
    are stored and how they are encrypted. I have no idea how to make that
    safe and as long as I don't know that, I won't do it.


    Corinna

    --
    Corinna Vinschen
    Cygwin Project Co-Leader
    Red Hat
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread