I just wanted to let people know that I found the solution to my problem. Apparently hostbased authentication doesn't work for the root user. Creating the proper /root/.ssh/{id_dsa{,.pub},authorized_keys} files allows root to login to the other nodes without a problem. Now with hostbased working for the users, I don't have to create those same files for any new accounts that get added. Bryan -- Aspen Systems, Inc. | http://www.aspsys.com/ Production Engineer | Phone: (303)431-4606 bryans@aspsys.com | Fax: (303)431-7196 On Wed, Sep 08, 2004 at 12:14:12PM -0600, Bryan Stillwell wrote:
I hate to respond to myself, but I found that if I set the following, the key disallowed error goes away:
UsePrivilegeSeparation no
I've known about privilege separation, but I guess I didn't think it would be turned on by default... However, the problem still persists. The debug messages are as follows:
debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug2: input_userauth_request: setting up authctxt for root debug1: PAM: initializing for "root" debug3: Normalising mapped IPv4 in IPv6 address debug3: Trying to reverse map address 10.1.1.128. debug1: PAM: setting PAM_RHOST to "master" debug1: PAM: setting PAM_TTY to "ssh" debug2: input_userauth_request: try method none Failed none for root from ::ffff:10.1.1.128 port 39095 ssh2 debug1: userauth-request for user root service ssh-connection method hostbased debug1: attempt 1 failures 1 debug2: input_userauth_request: try method hostbased debug1: userauth_hostbased: cuser root chost master. pkalg ssh-dss slen 55 debug2: userauth_hostbased: chost master. resolvedname master ipaddr ::ffff:10.1.1.128 debug2: stripping trailing dot from chost master. debug2: auth_rhosts2: clientuser root hostname master ipaddr ::ffff:10.1.1.128 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug2: userauth_hostbased: authenticated 0 Failed hostbased for root from ::ffff:10.1.1.128 port 39095 ssh2
Thanks, Bryan
-- Aspen Systems, Inc. | http://www.aspsys.com/ Production Engineer | Phone: (303)431-4606 bryans@aspsys.com | Fax: (303)431-7196
On Wed, Sep 08, 2004 at 09:55:15AM -0600, Bryan Stillwell wrote:
I'm running into a problem on SuSE 9.1 Professional for AMD64 where hostbased authentication doesn't seem to be working properly...
In /etc/ssh/sshd_config and /etc/ssh/ssh_config I have it turned on:
HostbasedAuthentication yes
I've also turned on:
PermitRootLogin yes
In /etc/ssh/shosts.equiv I have the proper entry:
master 10.1.1.128
But when I try to log in, it asks for the password. When running sshd with debugging turned on (sshd -d -d -d -p 2222), it reports the following (snipped for briefness):
debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 debug3: mm_getpwnamallow entering debug3: mm_request_send entering: type 6 debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM debug3: mm_request_receive_expect entering: type 7 debug3: mm_request_receive entering debug3: monitor_read: checking request 6 debug3: mm_answer_pwnamallow debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send entering: type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_request_receive entering debug2: input_userauth_request: setting up authctxt for root debug3: mm_start_pam entering debug3: mm_request_send entering: type 45 debug3: monitor_read: checking request 45 debug3: mm_inform_authserv entering debug1: PAM: initializing for "root" debug3: mm_request_send entering: type 3 debug2: input_userauth_request: try method none Failed none for root from ::ffff:10.1.1.128 port 38469 ssh2 debug1: userauth-request for user root service ssh-connection method hostbased debug1: attempt 1 failures 1 debug2: input_userauth_request: try method hostbased debug1: userauth_hostbased: cuser root chost master. pkalg ssh-dss slen 55 debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug3: Normalising mapped IPv4 in IPv6 address debug3: Trying to reverse map address 10.1.1.128. debug1: PAM: setting PAM_RHOST to "master" debug1: PAM: setting PAM_TTY to "ssh" debug2: monitor_read: 45 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 3 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 3 used once, disabling now debug3: mm_request_receive entering debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x55cb20 debug2: userauth_hostbased: chost master. resolvedname master ipaddr ::ffff:10.1.1.128 debug2: stripping trailing dot from chost master. debug2: auth_rhosts2: clientuser root hostname master ipaddr ::ffff:10.1.1.128 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: key 0x55cb20 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug2: userauth_hostbased: authenticated 0 Failed hostbased for root from ::ffff:10.1.1.128 port 38469 ssh2
I believe the problem is in "mm_answer_keyallowed: key 0x55cb20 is disallowed", but I don't know why it's being rejected... Does anyone have any ideas? I've even tryed chmod'ing /usr/lib64/ssh/ssh-keysign to be suid root (4755) without success...
Thanks, Bryan