SOLVED: SSHD “/bin/bash:permission denied” on Windows 7

I’ve been having a hard time getting sshd to accept logins on a Windows 7 x64 box. The problems ranged from the error mentioned in the subject line (“/bin/bash: permission denied” appearing during logins) to silent failures during password authentication, during which the ssh
connection would simply be closed by the instance of Cygwin sshd running on my machine.

As it turns out, all my problems were caused by the fact that the sshd_server user being created by the ssh-host-config script was not being given all the required privileges. I’m not sure why, but I found an online description of the rights required by sshd_server and used the
“editrights” utility to grant them. I then deleted my ~/.ssh directory (definitively to erase the known_hosts file), restarted sshd, and everything began to work perfectly.

Unfortunately, I neglected to record which privileges had been granted to the sshd_server user on my system before I started granting additional ones, but as far as I remember sshd_server only had 2 or so of the 8 privileges granted.

In case the information helps anyone else, here is a list of the privileges that the sshd_server user appears to need:

SeIncreaseQuotaPrivilege
SeTcbPrivilege
SeAssignPrimaryTokenPrivilege
SeCreateTokenPrivilege
SeServiceLogonRight
SeDenyInteractiveLogonRight
SeDenyNetworkLogonRight
SeDenyRemoteInteractiveLogonRight

To determine which privileges sshd_server has on your system, use this
command:

editrights -u sshd_server -l

And here are the commands necessary to grant the above privileges to
sshd_server:

editrights -a SeTcbPrivilege -u sshd_server
editrights -a SeAssignPrimaryTokenPrivilege -u sshd_server
editrights -a SeCreateTokenPrivilege -u sshd_server
editrights -a SeDenyInteractiveLogonRight -u sshd_server
editrights -a SeDenyNetworkLogonRight -u sshd_server
editrights -a SeDenyRemoteInteractiveLogonRight -u sshd_server
editrights -a SeIncreaseQuotaPrivilege -u sshd_server
editrights -a SeServiceLogonRight -u sshd_server

11 Comments »

  1. avatar Selinsa Says:

    very well information you write it very

    clean. I’m very lucky to get this information from you.

  2. avatar Nicholas Fone Says:

    Thanks Ankur. Great article!

    Btw, the list of privileges that the sshd_server user needs is defined in:
    /usr/share/csih/cygwin-service-installation-helper.sh

    The above script is called by the install script for sshd: ssh-host-config

    I believe the privileges are only required if sshd is configured to use “privilege separation”, though it is most likely less secure to run sshd without “privilege separation”.

    In our case, we suspect that some of the required privileges on the sshd_server user were being deleted periodically, perhaps by some “helpful” security auditing software, which is quite likely as we’re in a large corporate environment :)

    Cheers,
    Nick

  3. avatar Nicholas Fone Says:

    Actually, I just confirmed, a privileged user *is* created, even when “privilege separation” is used for sshd.

    Cheers,
    Nick

  4. avatar Nicholas Fone Says:

    Correction to my post above (dated June 25th, 2010 at 2:10pm):

    A privileged user is created by ssh-host-config, regardless of whether the answer to the “privilege separation” question is “yes” or “no”.

    Cheers,
    Nick

  5. avatar Mike Says:

    @Ankur Shah: I experienced the same problem several times by now. For me it seems as if the sshd-host-config script isn’t able to set these privileges correctly on Domain Controllers. After I used the editrights commands above I was able to render sshd usable on all trouble-machines.

    @Nicholas Fone: YES – the privileges may be overwritten by group policies pushed from the each Domain Controller. This mustn’t be caused by auditing software. Just check back with the Microsoft Infrastructure Admins of your company – they could even setup a domain user account to be used with the local sshd-installs for you (easier managemen: only one user for all sshd-installs instead of one local account on each sshd-enabled machine).

  6. avatar BellsTheorem Says:

    Thanks so much!!!!
    Here’s how i got sshd working on win7. (i am using username sshd rather than sshd_server)
    I started with http://pigtail.net/LRP/printsrv/cygwin-sshd.html
    and then
    chown sshd /etc/ssh*
    chown sshd /var/empty

    After running ssh-host-config , i had to open up Computer Manager / local user and groups and select properties for the sshd user and untick “disabled” and tick “password never expires”

    After all that, i was getting the /bin/bash: Permission denied problem and found your page and run the following and then it all worked !!

    editrights -a SeTcbPrivilege -u sshd
    editrights -a SeAssignPrimaryTokenPrivilege -u sshd
    editrights -a SeCreateTokenPrivilege -u sshd
    editrights -a SeDenyInteractiveLogonRight -u sshd
    editrights -a SeDenyNetworkLogonRight -u sshd
    editrights -a SeDenyRemoteInteractiveLogonRight -u sshd
    editrights -a SeIncreaseQuotaPrivilege -u sshd
    editrights -a SeServiceLogonRight -u sshd

    I would have never figured that out!

  7. avatar BellsTheorem Says:

    Also, add sshd to administrators group in windows user management.

  8. avatar PhilMill Says:

    Thank you so much for this entry. I would have never figured this one out.

    Had to map these permissions over to Group Policy, and figured others might need to know the mappings.
    All setting are in Local Security Settings -> Local Policies -> User Rights (UR):

    SeTcbPrivilege -> UR:Act as part of OS
    SeAssignPrimaryTokenPrivilege -> UR:Impersonate a client after auth
    SeCreateTokenPrivilege -> UR:Create a token object
    SeDenyInteractiveLogonRight -> UR:Deny log on locally
    SeDenyNetworkLogonRight -> UR:Deny Access to this computer from the network
    SeDenyRemoteInteractiveLogonRight -> Deny login through TS
    SeIncreaseQuotaPrivilege -> UR:Adjust memory quotas for a process
    SeServiceLogonRight -> UR:Log on as a service

    Cheers,
    Phil

  9. avatar philmill Says:

    **I put the wrong UR on:
    SeAssignPrimaryTokenPrivilege -> UR:Impersonate a client after auth

    It should be:
    SeAssignPrimaryTokenPrivilege -> UR:Replace a process level token

    (UR:Impersonate a client after auth -> SeImpersonatePrivilege)

    Sorry about that.

  10. avatar nemo Says:

    very good article.
    concise, succinct and accurate.

    (another user whose working sshd stopped after an apparently group policy push on a corporate network)

    thank you, Ankur, you helped many people

  11. avatar Glenn E Says:

    Thanks! This fixed my problem as well. My user was named cyg_server. You can determine the user easily by running ps -ef.

RSS feed for comments on this post. TrackBack URL

Leave a comment