Error:
$ net start sshd
System error 1068 has occurred.
The dependency service or group failed to start.

Fix: login to the server (bash --login -i) and issue the following command:

$ passwd ssh_service
Enter the new password and restart the service.

Issue:
when using authorized keys for remote admin account logg into ssh server and it still prompt for password:

ssh RemodAdmin@myserver
RemoteAdmin@myserver's password:

Cause:
use ssh –vv 10.42.10.12 to get debug information, or look in your logs on the target machine
Most common problems are:

• Permissions on files or directories are very strict
• Key is copy/pasted on two or more lines in authorized_keys file

Fix:
Make sure the following things:
1 The RemoteAdmin account does created in the taget system
2 The RemoteAdmin account shows up in /etc/passwd file
3 The RemoteAdmin folder and its subfolder .ssh are creaded in ssh home directory and RemoteAdmin has full rights for them
4 The authorized_keys file with valued key are exsist in .ssh folder and RemoteAdmin has full right of it
5 If there are multiple keys in authorized_keys file, each key only has one line.

Here is a article talking about Configuring OpenSSH (Win32) for Public Key Authentication
from: http://www.bmonday.com/articles/653.aspx

First, let me thank Anil John for sending me his configuration and walking me through the appropriate steps.  You rock, Anil, seriously.

Secondly, if you notice any errors in this article, or have suggestions for improvement, please leave a comment, or email me at beau dot monday at gmail dot com.

Installing and Configuring OpenSSH Server:

OK, first, download OpenSSH from http://sshwindows.sourceforge.net
Unzip it, and run the resulting installer
Install the program to the directory of your choice (I will use c:\OpenSSH).  You will be best served by putting OpenSSH into a directory that does not contain any spaces.
Take the defaults for the remaining setup screens
After OpenSSH is installed, open a command prompt and cd to the \OpenSSH\Bin directory
Run mkgroup -l >> ..\etc\group
Run  mkgroup -d >> ..\etc\group
Run mkpasswd -l [-u ] >> ..\etc\passwd
Run mkpasswd -d [-u ] >> ..\etc\passwd
Run “net start opensshd“
On a seperate system equipped with an SSH client (such as PuTTY), ensure you can connect to the new server using a username and password that is valid for the server
Once you have verified the OpenSSH service is working correctly, go ahead and “net stop opensshd“ to stop it
From the command window on the server, cd\openssh\etc
Copy sshd_config to sshd_config.bak just in case something goes horribly wrong and you want to return to the default configuration and start over
Copy this sshd_config to the system, placing it into the \OpenSSH\etc directory and remove the .txt extension(this conf file will force public key authentication, and disallow password authentication.  Feel free to adjust it to your needs later.)
cd ..\bin
Run “ssh-keygen -t rsa“ (we will be generating an SSH2 RSA key, which is the currently recommended key)
When asked for where we want the key files to be placed, DO NOT TAKE THE SUGGESTED LOCATION.  Instead enter “/etc/id_rsa“ (the use of “/“ is important here, you cannot use “\“)
Enter a passphrase (you can leave the passphrase blank, but a passphrase will prevent the key from being used if someone happens to acquire it)
Enter the passphrase a second time
Observe two files being generated, “id_rsa“ (your private key, which your client machines will need) and “id_rsa.pub“ (your public key, which stays on your server)
Run “cd ..\etc“
Perform a “dir“ and ensure the two files are there.  If they aren't go find them and put them there.
Run “copy id_rsa.pub authorized_keys“  The goal is to make a copy of the public key file, named “authorized_keys“
Grab the other file (id_rsa) and copy it by whatever means necessary (network, floppy, usb flash disk, pigeon, whatever it takes) to the machine you will be using as the client.  (This file is your private key, and should be treated as highly confidential.  If you used a well-thought-out passphrase when generating the key, then it is nigh unusable if someone comes across it.  Otherwise, if someone gets a hold of this file, they can IMPERSONATE YOU when connecting to your SSH server.  Pass phrase or not, this file should be treated as sensitive, and erased from whatever media you used to move it to your client.)
Run “net start opensshd“ and check in the Services applet that is has started and is running.
On the client, assuming you have SSH client tools installed, you can run “ssh -l “ from the directory where the id_rsa file was copied, and it should prompt you for the pass phrase, if you entered on during key generation.  Once the pass phrase is entered, it should connect to the SSH server and give you a command prompt.
Pat yourself on the back and have a beer, preferably Fat Tire.  But get your own.  Just because I have a keg in my kitchen does not mean I have enough to share with other people!
Configuring PuTTY to use your shiny new key:

PuTTY is a free terminal emulation program, and it pretty much kicks ass.  It supports all major encryption and authentication standards, and permits SSH tunnelling (which is what got me into this mess to begin with).  I highly recommend it.  You should go get it now and install it, if you haven't already.

First, the id_rsa file, your private key, needs to be converted to a format that PuTTY can work with:

Open a command prompt and navigate to the directory where PuTTY was installed
Run “puttygen“
Click “Load“
Change “Files of type:“ to “All Files (*.*)“
Navigate to where the id_rsa file was placed and select it, then click “Open“
If you set a pass phrase, you will be required to enter it before continuing
You should receive a Notice saying that the key has been successfully imported (blah blah blah).  Hit OK there.
Ensure the “SSH2 RSA“ radio button is selected at the bottom of the window, in the box entitled “Parameters“
Click “Save Private Key“
Note the location, or pick a new one, and save the file as “id_rsa.ppk“
Close puttygen, you're done with it.
Now, configure a new SSH session in PuTTY to connect to your OpenSSH server:

Run PuTTY
Enter the Host Name or IP Address in the “Host Name“ box towards the top of the main window
Ensure “SSH“ is selected in the “Protocol“ box
In the “Saved Sessions“ top box, enter a name for the session you are creating
In the tree on the left, expand the “Connection“ and “SSH“ sections, if necessary
Under the “SSH“ tree, highlight “Auth“
Hit the “Browse“ button next to the box that says “Private key file for authentication“
Locate the “id_rsa.ppk“ file and double click on it (or highlight it and click “Open“)
Highlight the “Session“ section in the treeview on the left
Click “Save“ to save the session you have just configured (from now on, you can simply double-click on that session name when you start PuTTY and it will load all the settings you just configured)
Click “Open“ at the bottom of the window, or double-click on the newly-created session in the list box to start it.
If all goes well, you should establish a connection to the remote OpenSSH server, and be prompted for a user name
Enter a user name that is valid on the remote server and hit return
If you have configured a pass phrase, you will be challenged for it now.  Otherwise...
You're done.  I think we've earned another Fat Tire, don't you?  I know I'm having another.
 

Pitfalls:

Directories with spaces in them MAY cause some issues with OpenSSH.  Avoid them.
Don't place your public key (id_rsa.pub and authorized_keys file) into your user directory, which is the default location for them when using “ssh-keygen“.  User dirs have funny permissions on them sometimes.  Use a neutral location, like the suggested “\OpenSSH\etc“ dir.
Remove the private key from the server, or at least move it to a more secure location.  This is the key to your kingdom.  Even with a pass phrase, it can be broken by a hacker with enough motivation, horsepower and time.
Don't be dazzled by all the things PuttyGen can do.  All you want to do it save the private key in the PuTTY format.  All the noise about pasting text into “authorized_keys“ and stuff is not necessary in the scenario we walked through here.  Ignore all that, follow my instructions (unless you know what you are doing, in which case, why the hell are you reading this drivel?).