Well, after a about a week of bashing my head against this, i figured out my mistake.  I decided to post it here in case anyone else was having a similar issue. So, authentication was the key.  For pubkey to work, you have to set the ssh authentication to NONE.  Yes, none.  If you have it set to LOCAL, it will only authenticate you using the local user database password list, even if pubkey-auth is enabled.  Same with LINE, or ENABLE. (different password lists, same effect).  SSH was written to support multiple authentication, so what was happening was that it negotiated a pubkey authentication, signed it, said it was good, then the switch checked it's authorization lists and noticed that it only accepted password authentication, so it told SSH that it succeeded with the pubkey-auth, but it was only partial success as it still needed a password.  Seems kinda obvious now, but it didn't know that pubkey-auth was an either / or situation.  Either you have pubkey-auth enabled and use certs to login, or you use the different password lists (or RADIUS / TACACS if you're into that stuff).  You can't have both, which is what threw me.
Hi all,      First time poster to Dell forums, so please excuse any noobness.  I'm having some severe issues getting Single Sign On working through Public key authentication; specifically, it just plain doesn't seem to work at all.  Setting up SSH wasn't any problem, and once i found the joy of "quotes" importing my public key to my administrative user account on the switch also wasn't an issue.  what is happening is that when i ssh from my terminal to the switch, it checks the key, accepts the key, "Authenticated with partial success" and then decides to ask for a password anyway.  Long story short, how can i get the switch to stop auto asking for a password?  This user was setup with nopassword (just cause) so simply hitting enter lets you in, but why the hell is it asking in the first place if it public key authenticated me?  Also, just because i've been bashing my head against this for days, i tried signing in with the wrong key, and 'lo and behold, the public key fails.....but procedes to ask for a password anyway, and if you enter the right password (i.e. none) it lets you in!?!  I'm having some trouble with this.   Here is what SSH verbose is spitting back out for me: $ ssh -i id_dsa 10.10.10.11 -vvvOpenSSH_5.2p1, OpenSSL 0.9.8r 8 Feb 2011debug1: Reading configuration data /etc/ssh_configdebug1: Applying options for *debug3: cipher ok: blowfish-cbc [blowfish-cbc]debug3: ciphers ok: [blowfish-cbc]debug2: ssh_connect: needpriv 0debug1: Connecting to 10.10.10.11 [10.10.10.11] port 22.debug1: Connection established.debug3: Not a RSA1 key file id_dsa.debug2: key_type_from_name: unknown key type '-----BEGIN'debug3: key_read: missing keytypedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug3: key_read: missing whitespacedebug2: key_type_from_name: unknown key type '-----END'debug3: key_read: missing keytypedebug3: key_read: missing whitespacedebug1: identity file id_dsa type -1debug1: Remote protocol version 1.99, remote software version OpenSSH_4.3debug1: match: OpenSSH_4.3 pat OpenSSH_4*debug1: Enabling compatibility mode for protocol 2.0debug1: Local version string SSH-2.0-OpenSSH_5.2debug2: fd 3 setting O_NONBLOCKdebug1: SSH2_MSG_KEXINIT sentdebug1: SSH2_MSG_KEXINIT receiveddebug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1debug2: kex_parse_kexinit: ssh-rsa,ssh-dssdebug2: kex_parse_kexinit: blowfish-cbcdebug2: kex_parse_kexinit: blowfish-cbcdebug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64[NAME].com,hmac-ripemd160,hmac-ripemd160[NAME].com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64[NAME].com,hmac-ripemd160,hmac-ripemd160[NAME].com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: none,zlib[NAME].com,zlibdebug2: kex_parse_kexinit: none,zlib[NAME].com,zlibdebug2: 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-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1debug2: kex_parse_kexinit: ssh-rsa,ssh-dssdebug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc[NAME].liu.se,aes128-ctr,aes192-ctr,aes256-ctrdebug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc[NAME].liu.se,aes128-ctr,aes192-ctr,aes256-ctrdebug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160[NAME].com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160[NAME].com,hmac-sha1-96,hmac-md5-96debug2: kex_parse_kexinit: none,zlib[NAME].comdebug2: kex_parse_kexinit: none,zlib[NAME].comdebug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5debug1: kex: server->client blowfish-cbc hmac-md5 nonedebug2: mac_setup: found hmac-md5debug1: kex: client->server blowfish-cbc hmac-md5 nonedebug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_GROUPdebug2: dh_gen_key: priv key bits set: 132/256debug2: bits set: 1007/2048debug1: SSH2_MSG_KEX_DH_GEX_INIT sentdebug1: expecting SSH2_MSG_KEX_DH_GEX_REPLYdebug3: check_host_in_hostfile: filename /Users/jbw/.ssh/known_hostsdebug3: check_host_in_hostfile: match line 3debug1: Host '10.10.10.11' is known and matches the RSA host key.debug1: Found key in /Users/jbw/.ssh/known_hosts:3debug2: bits set: 1013/2048debug1: ssh_rsa_verify: signature correctdebug2: kex_derive_keysdebug2: set_newkeys: mode 1debug1: SSH2_MSG_NEWKEYS sentdebug1: expecting SSH2_MSG_NEWKEYSdebug2: set_newkeys: mode 0debug1: SSH2_MSG_NEWKEYS receiveddebug1: SSH2_MSG_SERVICE_REQUEST sentdebug2: service_accept: ssh-userauthdebug1: SSH2_MSG_SERVICE_ACCEPT receiveddebug2: key: id_dsa (0x0)debug1: Authentications that can continue: publickey,password,keyboard-interactivedebug3: start over, passed a different list publickey,password,keyboard-interactivedebug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,passworddebug3: authmethod_lookup publickeydebug3: remaining preferred: keyboard-interactive,passworddebug3: authmethod_is_enabled publickeydebug1: Next authentication method: publickeydebug1: Trying private key: id_dsadebug1: read PEM private key done: type DSAdebug3: sign_and_send_pubkeydebug2: we sent a publickey packet, wait for replyAuthenticated with partial success.debug1: Authentications that can continue: passworddebug3: start over, passed a different list passworddebug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,passworddebug3: authmethod_lookup passworddebug3: remaining preferred: ,gssapi-with-mic,publickey,keyboard-interactive,passworddebug3: authmethod_is_enabled passworddebug1: Next authentication method: passwordjbw[NAME].10.10.11's password: debug3: packet_send2: adding 8 (len 48 padlen 8 extra_pad 64)debug2: we sent a password packet, wait for replydebug1: Authentication succeeded (password).debug1: channel 0: new [client-session]debug3: ssh_session2_open: channel_new: 0debug2: channel 0: send opendebug1: Entering interactive session.debug2: callback startdebug2: x11_get_proto: /usr/X11R6/bin/xauth  list /tmp/launch-R6A2wW/:0 2>/dev/nullWarning: No xauth data; using fake authentication data for X11 forwarding.debug1: Requesting X11 forwarding with authentication spoofing.debug2: channel 0: request x11-req confirm 0debug2: client_session2_setup: id 0debug2: channel 0: request pty-req confirm 1debug2: channel 0: request shell confirm 1debug2: fd 3 setting TCP_NODELAYdebug2: callback donedebug2: channel 0: open confirm rwindow 0 rmax 32768debug2: channel_input_status_confirm: type 99 id 0debug2: PTY allocation request accepted on channel 0debug2: channel 0: rcvd adjust 131072debug2: channel_input_status_confirm: type 99 id 0debug2: shell request accepted on channel 0console>   AND just because i know you can't wait to see it, here is my switch config (light and sparse i know, but that's cause i'm trying to fix this one issue) console#show running-config !Current Configuration:!System Description "PowerConnect 6248, 3.3.1.10, VxWorks 6.5"!System Software Version 3.3.1.10!Cut-through mode is configured as disabled!configurestackmember 1 2exitip address 10.10.10.11 255.0.0.0no passwords min-lengthusername "admin" password a7ad134c2b7cdb2fd906a573e14b58be level 15 encryptedusername "jbw" password d41d8cd98f00b204e9800998ecf8427e level 15 encryptedcrypto key pubkey-chain sshuser-key "jbw" dsakey-string row  AAAAB3NzaC1kc3MAAACBAIkMYpQ7OBLdzn60VhO9FuHj7ZE9zoWSdS0Kczslrrb9SGmTNYRHogxmczWa4KInWCPziUziX7uY19GcxCZmx+ZMo4kbGiJ+UlQMrfpgsntlr7q/pufWJ9Qt439IeyJ2u20Wbyv8hgoCe4gIFj1t43Q/r7rfXmqNptKGPZUT/DO/AAAAFQD8Uc9Il8DgOmOpIribCXiytmnqvwAAAIApSliT0w/4xtP93g/fAmGhQe6rZTmegJgCCURi3eBix1muVIV2slDL19RfjqP2Dl0cU/YK2qO2u4YpXNOz1Mi74xN1h4w5mWxADRyZ/neF/mxT+q1kWcslHhcKC/qxb7uh3k86BxgYyQD8Q4Ykoc9PBGzViaWg+XW5zd5hfpexZQAAAIBx1v6Tc92/XWiSUwFFG/UFnBm93Gy3TJEc+A13sGbpz36bBEwaalIGMdkQVQWclzSbpDh1T8bSdNyQ5kWqYLQ/N1R/IBooiaiVpq/QT5EGoV12Y/yh4fmWlGhIMl5swxQiPDA6Y9ElG8CRfgO8++4APpZZOKHVxHTl1/9KeT1uew==exitexitip ssh serverip ssh pubkey-authexit     So, i ask you, no i implore you, please tell me what stupid error i'm making that is preventing me from getting public key to work properly.  Thanks in advance.
PowerConnect 6248 - Pubkey Authentication a joke?