I recently compiled 4.7p1 in anticipation of upgrading our current (3.6.1p2) running version -- by no means ahead of schedule, granted. However, I seem to be unable to get hostbased authenticaton to work. This should have been a simple question of checking sshd_config, ensuring correct host keys are present, and checking file permissions. Failing that, verbose output from a test client and daemon should be able to tell me exactly where the problem lies. Not so fast, though: sshd-4.7p1 has the following to say when invoked with 'sshd -Dddd -p2222 -f <sshd_config provided below>' and ssh 3.6.1p2 is called with 'ssh -vvv serverhost -p2222': <snip daemon setup and publickey, which I don't try for here:> debug2: input_userauth_request: try method hostbased debug1: userauth_hostbased: cuser root chost clienthost. pkalg ssh-dss slen 55 debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x14267f60 debug2: userauth_hostbased: chost clienthost. resolvedname clienthost.uio.no ipaddr <IPv4addr> debug2: auth_rhosts2: clientuser root hostname clienthost. ipaddr clienthost. 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 Failed hostbased for root from <IPv4addr> port 712 ssh2 debug3: mm_answer_keyallowed: key 0x14267f60 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug2: userauth_hostbased: authenticated 0 debug1: userauth-request for user root service ssh-connection method hostbased debug1: attempt 3 failures 3 debug2: input_userauth_request: try method hostbased debug1: userauth_hostbased: cuser root chost clienthost. pkalg ssh-rsa slen 143 debug3: mm_key_allowed entering debug3: mm_request_send entering: type 20 debug3: monitor_read: checking request 20 debug3: mm_answer_keyallowed entering debug3: mm_answer_keyallowed: key_from_blob: 0x142679d0 debug2: userauth_hostbased: chost clienthost. resolvedname clienthost.uio.no ipaddr <IPv4addr> debug2: auth_rhosts2: clientuser root hostname clienthost. ipaddr clienthost. 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 Failed hostbased for root from <IPv4addr> port 712 ssh2 debug3: mm_answer_keyallowed: key 0x142679d0 is disallowed debug3: mm_request_send entering: type 21 debug3: mm_request_receive entering debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED debug3: mm_request_receive_expect entering: type 21 debug3: mm_request_receive entering debug2: userauth_hostbased: authenticated 0 Connection closed by <IPv4addr> debug1: do_cleanup ssh on the clienthost should have its say, too: debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password,hostbased debug2: we did not send a packet, disable method debug3: authmethod_lookup hostbased debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled hostbased debug1: Next authentication method: hostbased debug2: userauth_hostbased: chost clienthost. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,hostbased debug2: userauth_hostbased: chost clienthost. debug2: we sent a hostbased packet, wait for reply debug1: Authentications that can continue: publickey,password,hostbased debug1: No more client hostkeys for hostbased authentication. debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password root@serverhost's password: My sshd_config looks like this: # $OpenBSD: sshd_config,v 1.75 2007/03/19 01:01:29 djm Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin:/local/bin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. Port 22 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # Disable legacy (protocol version 1) support in the server for new # installations. In future the default will change to require explicit # activation of protocol 1 Protocol 2 # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key #(COMMENT: I included this on the go because I suspected DNS mismatch between #clienthost and clienthost.domain.name was the cause of the problem.) HostbasedUsesNameFromPacketOnly yes # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m PermitRootLogin yes #StrictModes yes MaxAuthTries 10 #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys #(COMMENT: I dont't want protocol version 1): # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts RhostsRSAAuthentication no # similar for protocol version 2 #(If I had a dime for each time I checked this one...) HostbasedAuthentication yes # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #(COMMENT: I trust my users to do this) IgnoreRhosts no # To disable tunneled clear text passwords, change to no here! PasswordAuthentication yes #PermitEmptyPasswords no # Change to no to disable s/key passwords #(COMMENT: I believe this should be disabled if hostbased is to work) ChallengeResponseAuthentication no # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication and # PasswordAuthentication. Depending on your PAM configuration, # PAM authentication via ChallengeResponseAuthentication may bypass # the setting of "PermitRootLogin without-password". # If you just want the PAM account and session checks to run without # PAM authentication, then enable this but set PasswordAuthentication # and ChallengeResponseAuthentication to 'no'. UsePAM yes #COMMENT: (I wish to enable PAM, but I can renege on this for the moment. #In the long run, it will have to work. Disabling it doesn't seem to make #a difference right now anyhow.) XAuthLocation /usr/bin/xauth #AllowTcpForwarding yes #GatewayPorts no X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost no PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 #PermitTunnel no # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /local/libexec/sftp-server # Example of overriding settings on a per-user basis #Match User anoncvs # X11Forwarding no # AllowTcpForwarding no # ForceCommand cvs server My /etc/ssh/ directory looks like this, for those curious about my file permissions: -rw-r--r-- 1 root root 15 2008-02-26 16:53 hosts.equiv -rw------- 1 root root 132839 2007-07-13 17:01 moduli -rw-r--r-- 1 root root 15 2008-02-26 15:02 shosts.equiv -rw-r--r-- 1 root root 1600 2008-02-26 16:07 ssh_config -rw-r--r-- 1 root root 1495 2008-02-25 17:50 ssh_config.old -rw-r--r-- 1 root root 3289 2008-02-26 17:24 sshd_config -rw-r--r-- 1 root root 3289 2008-02-26 17:23 sshd_config.current -rw-r--r-- 1 root root 3297 2008-02-25 18:10 sshd_config.old -rw------- 1 root root 668 2008-02-25 17:01 ssh_host_dsa_key -rw-r--r-- 1 root root 610 2008-02-25 17:01 ssh_host_dsa_key.pub -rw------- 1 root root 983 2008-02-25 17:01 ssh_host_key -rw-r--r-- 1 root root 647 2008-02-25 17:01 ssh_host_key.pub -rw------- 1 root root 1675 2008-02-25 17:01 ssh_host_rsa_key -rw-r--r-- 1 root root 402 2008-02-25 17:01 ssh_host_rsa_key.pub -rw-r--r-- 1 root root 230 2008-02-26 15:12 ssh_known_hosts -rw-r--r-- 1 root root 229 2008-02-26 15:12 ssh_known_hosts2 -rw-r--r-- 1 root root 1333 2008-02-26 15:11 ssh_known_hosts2.bak -rw-r--r-- 1 root root 474 2008-02-26 15:11 ssh_known_hosts.bak Whereas ssh on the clienthost, naturally, is setuid root (as it should be to work with hostbased for root to other hosts). I've tried copying my /.rhosts into /.shosts. I've checked and double-checked that the host keys are exactly the same, and I've also used ssh-keyscan (does it still assume rsa1 is the default?) to ensure that they're updated. Somewhere along the way I came over the string "shosts.equiv", and added the line '+ clienthost.domain.name' to it, equally for hosts.equiv. I guess I should've assumed they wouldn't do much, but there you are. Our old OpenSSH-3.6.1p2 installation didn't use ssh-keysign; at least, it isn't present in /usr/libexec. ssh is setuid root on the client. It works beautifully to other serverhosts that run the same version. I have as far as possible attempted to mimic the existing config files of ssh and sshd of 3.6.1p2 in 4.7p1, but I am wary of trusting this approach. Under any circumstance, there aren't *that* many options to begin with in either file which regulate hostbased a'n, is there? Is there an updated checklist somewhere that applies to the later versions of OpenSSH that I can use as an authoritative resource on the issue of hostbased a'n? The various resources available seem to diverge somewhat, and I have a distinct feeling I'm turning knobs in mid-air. Failing that, if someone sees glaring mistakes, now's the chance to earn eternal glory. In advance thanks for any helpful pointers. -- Øystein Larsen <oystein.larsen@xxxxxxxxxxx>
