Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm attempting to set up key-based authentication on an OpenSSH server running on Windows. Unfortunately, the server doesn't seem to be accepting the key I am providing, but I can't see any specfic error message or reason for the error. Here's the steps I've attempted so far:

General Setup

  1. Set up a specific domain account to access the server. In this case, we set up one service account that is able to access the server, and generated group and passwd files using mkgroup and mkpasswd.
  2. Verified that password-based authentication works properly.
  3. Modified the passwd file to change the users home directory to a specified folder on the D: drive using "/cygdrive/d/share"

Key Setup

  1. Modified ssh_config to include the following two lines:

    RSAAuthentication yes

    PubkeyAuthentication yes

  2. Ran ssh-keygen to generate a public and private key for the user.
  3. Copied the contents of the public key to D:\Share\.ssh\authorized_keys
  4. Ran the following to test connection to the SSH server:

    ssh -v -l CRMETLSFTP -i id_crmftp SERVERNAME

As far as I can tell, these should be the necessary steps. When I connect with PuTTy remotely (after converting the private key), I get "Server refused our key". Testing a connection locally with -v, I get the following output:

C:\Program Files (x86)\OpenSSH>ssh -v -l CRMETLSFTP -i id_crmftp DEVCRMETL01
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to DEVCRMETL01 [172.17.8.151] port 22.
debug1: Connection established.
debug1: identity file id_crmftp type 1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'devcrmetl01' is known and matches the RSA host key.
debug1: Found key in /home/rbrunner/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: publickey
debug1: Offering public key: id_crmftp
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interacti
ve
debug1: Next authentication method: password
CRMETLSFTP@devcrmetl01's password:

As far as I can see, it is attempting to send the key properly. I assume the authorized keys is not picking up properly, but I'm not sure where to start looking.

share|improve this question
    
Server logs will most likely tell you what's going wrong. –  womble Nov 18 '09 at 16:06
    
Dumb question, but have you double-checked the permissions on authorized_keys? Should be 600. I've had this bite me too often. –  ajdecon May 3 '11 at 1:11

1 Answer 1

It's a little late for an answer perhaps, but just in case someone else comes accross this question I would try the following.

  • Copy authorized_keys to authorized_keys2.
  • Run ssh-user-config to make sure permissions and such are correct.
  • Start sshd with the -d, -dd and -ddd parameters for it not to fork and print debug information in the foreground while testing. This usually is more helpful than increasing debugging information (-vvv) on the client.
share|improve this answer
    
FWIW, authorized_keys2 has been deprecated since 2001. –  grawity Aug 29 '11 at 11:09
    
@grawity I didn't know it was that long ago! As 3.8 is quite old (around 2004) I thought it was worth trying. Good point. –  Eduardo Ivanec Aug 29 '11 at 13:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.