SSH Public Key Authentication w/t Domain Accounts

[azmiahmad]

I have installed VShell for windows on a Windows XP machine.

I am able to login through ssh, as domain as well as local users, with password authentication.

Although it successfully authenticates local users with Public Key Authentication, domain users login fails with the message:
Authenticated with partial success
<USER>@<HOSTS>'s password:


How do I enable Domain logins over SSH with RSA Public Key Authentication?

Any Suggestions.....

Azmi

[Duckling]

We have not had problems doing this.
There is nothing different in this setup than for local users.
At least, this works for us.

What does the VShell server log say?
Does the server require password authentication,
but you only specify a key?

Cheers,
Anders

[azmiahmad]

Logs:

on linux machine using OpenSSH client
OpenSSH_3.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 10164 geteuid 0 anon 1
debug1: Connecting to pc-cube-1026 [10.10.16.225] port 22.
debug1: temporarily_use_uid: 10164/100 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 10164/100 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/azmi/.ssh/identity type -1
debug3: Not a RSA1 key file /home/azmi/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /home/azmi/.ssh/id_rsa type 1
debug1: identity file /home/azmi/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version VShell_2_3_3_217 VShell
debug1: no match: VShell_2_3_3_217 VShell
Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1
debug2: kex_parse_kexinit: ssh-dss
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
debug2: kex_parse_kexinit: aes128-cbc,aes192-cbc,aes256-cbc,twofish-cbc,blowfish-cbc,3des-cbc,arcfour
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-cbc hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: dh_gen_key: priv key bits set: 130/256
debug1: bits set: 1031/2047
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug3: check_host_in_hostfile: filename /home/azmi/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 4
debug3: check_host_in_hostfile: filename /home/azmi/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 4
debug1: Host 'pc-cube-1026' is known and matches the DSA host key.
debug1: Found key in /home/azmi/.ssh/known_hosts:4
debug1: bits set: 1051/2047
debug1: ssh_dss_verify: signature correct
debug1: kex_derive_keys
debug1: newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: waiting for SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug1: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug1: authentications that can continue: password,publickey,gssapi-with-mic
debug3: start over, passed a different list password,publickey,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: next auth method to try is publickey
debug1: try privkey: /home/azmi/.ssh/identity
debug3: no such identity: /home/azmi/.ssh/identity
debug1: try pubkey: /home/azmi/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: input_userauth_pk_ok: pkalg ssh-rsa blen 149 lastkey 0x8087d88 hint 1
debug2: input_userauth_pk_ok: fp 67:aa:a1:eb:ba:e9:42:42:e1:05:97:06:94:36:51:75
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
Authenticated with partial success.
debug1: authentications that can continue: password,gssapi-with-mic
debug3: start over, passed a different list password,gssapi-with-mic
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,keyboard-interactive,password
debug3: authmethod_is_enabled password
debug1: next auth method to try is password
azmi@pc-cube-1026's password:


on VShell server on win32 machine
04:37:17,conn,00001: Connection accepted from 10.10.200.115:57807.
04:37:17,auth,00001: none for user azmi rejected because it is unavailable.
04:37:17,auth,00001: Received unsigned public key; checking authorization (fingerprint: 67:aa:a1:eb:ba:e9:42:42:e1:05:97:06:94:36:51:75)
04:37:17,auth,00001: Searching C:\PROGRA~1\VShell\PublicKey\azmi for matching public key.
04:37:17,auth,00001: id_rsa.pub contains matching public key for user azmi
04:37:17,auth,00001: Received signed public key; attempting authentication (fingerprint: 67:aa:a1:eb:ba:e9:42:42:e1:05:97:06:94:36:51:75)
04:37:17,auth,00001: Searching C:\PROGRA~1\VShell\PublicKey\azmi for matching public key.
04:37:17,auth,00001: id_rsa.pub contains matching public key for user azmi
04:37:17,auth,Public-key only authentication for user azmi failed: The user's account was not found, or a failure occurred looking up the user's account information.
04:37:17,auth,00001: publickey for user azmi accepted, further authentication needed.

As you can see in client logs that it is using id_rsa as private key and it has found a corresponding id_rsa.pub on server.

This is the case when I try logging in as a domain user.

When I try login as local user, it logins with a key (no password required).

Azmi

[Duckling]

Not quite sure why you see this, but it looks to me like the Vshell server is trying to authenticate you to the domain (instead of just locally).
This always requires a password.

Our Win2K server does not care about authenticating to the domain, unless
we have something specified in the users profile that accesses a domain resource. For instance, we map SFTP roots to network shares.

When just making a shell connection, this passes through just fine without passwords, at least from PuTTy

Cheers,
Anders RM

[azmiahmad]

Looks Like I know what is going on here. The user who is trying to login is a domain user. He is coming from a Linux domain, which is controlled by NIS. My Windows machine is connected to a separate Active Directory Domain Controller. So to allow the NIS user into windows domain, we need some authentication on the windows domain, hence this is asking for the password. If I try this with local users, it works.

The VShell docs talk about GSSAPI, but setting that will be task then the reason why I want to set Public Key Authentication.

What I really want to do is I have some perl scripts which will ssh (using OpenSSH client) into specified machine execute the command and close the session. Why I want Public Key is that this script will ssh several times and I don’t want to supply password each time as it is something I want to do in an automated fashion.

Any alternatives/suggestions.....

Azmi

[kelli.burki]

This is a rather frustrating situation with respect to logging onto Windows machines and domains with a public-key only. The authentication API's that Microsoft provides are rather limiting at this point -- in that they seem to be pretty tied to having a password for domain access and resources.

I'm frustrated by the limits that the APIs provide. You mentioned earlier the kerberos possibilities, but I understand that is still somewhat limited in that it requires an original password in order to get a ticket -- tickets also expire after a while.

We do have someone researching additional authentication API options that might be available as of Windows 2003, so hopefully there might be some help there.

There are some limited things we can do today that might help your situation. With a little bit of a workaround, it is possible to authenticate a domain user with just a public-key. However, they will only have access to resources on the local machine. Will that help your situation at all?

[Ard]

Originally Posted by kelli.burki

There are some limited things we can do today that might help your situation. With a little bit of a workaround, it is possible to authenticate a domain user with just a public-key. However, they will only have access to resources on the local machine. Will that help your situation at all?

I'm in the same situation so it would help me
Can you put that workaround online ?

Thx !

[azmiahmad]

Kelli,
Thanx for your concern about this. But I am in a situation where I *have* to access network resources and these are authenticated using the windows login.

Anyway can Windows SFU's User Name Mapping be of some help here.

Azmi

[orbiter2001]

I have the same problem and would wish to have a work around.

I trying the same with cygwin on a windows 2003 domain controller. With a member server in the same domain I can authenticate with public key.

I made the same setup on the domain controller and I get the message from the DC "connection reset by peer" when I try to authenticate with public key. When I delete the id_rsa files then ssh server ask for password and the login works.

I just need local resources to backup the mail data from the linux server.

Please post the work around. Thanks!

Orbiter.

[mshioya]

I have a similar problem using smartcards to login into vshell.

The smartcard has a certificate issued by our internal CA for a domain user account. I can use the certificate to login to the domain for a Windows login, and also into an IIS web server setup to allow certificate authentication.

In case of vshell, I can use the cert to login as a local user on the vshell server, but not as a domain user.

I would really like to see the ability to use PKI to login as a domain user on vshell.

Is it possible to to do some type of smart card pass through? Citrix ICA clients already support smartcards for logins, and so does the Remote Desktop feature in Windows XP and 2003.

[jonvalencia]

I am also interested in the work around. I currently use local accounts with key authentication, but I would like to move them to our domain. I only need to access local resources so the workaround sounds fine.

Thanks,

jonvalencia

[baksteen]

Any chance that workaround might still be posted?
I am in dire need of it, we are experiencing the exact same problem and for us it's mandatory to have people logging on from different domains using just the Public key authentication.

It's no problem the users will only have local access to the server.

Thanks!

[jdev]

Originally Posted by baksteen

Any chance that workaround might still be posted?

As the current workaround for this public key only authentication problem is temporary, we've been working with folks on an individual basis to get a better understanding of their network environment and provide details of a workaround where applicable. Our goal is to be able to provide a more permanent solution that can be applied more generally. As soon as such a solution is developed, it will be documented as part of VShell's help (and we'll likely post the solution here as well ).

If you would like the specifics of the current/temporary workaround so that you can test it out in your environment, please send e-mail to support@vandyke.com referencing this forum thread (#510).



--Jake