Ticket #169 (new defect) Opened 1 month ago ssh does not time out if kdc is unavailable Reported by: kmacmill Assigned to: Priority: major Milestone: release-2 Component: other Version: Keywords: Cc: Description ¶ If you have kerberos tickets but the kdc is down, trying to ssh to *any* host for which you don't have tickets hangs and doesn't seem to time out.
Works for me on a Fedora 7 client: % kdestroy % kinit admin stop KDC on IPA server % slogin -v admin.com ... 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,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Cannot contact any KDC for requested realm debug1: Unspecified GSS failure. Minor code may provide more information Cannot contact any KDC for requested realm debug1: Unspecified GSS failure. Minor code may provide more information Cannot contact any KDC for requested realm debug1: Next authentication method: publickey debug1: Trying private key: /home/rcrit/.ssh/identity debug1: Trying private key: /home/rcrit/.ssh/id_rsa debug1: Trying private key: /home/rcrit/.ssh/id_dsa debug1: Next authentication method: password admin.com's password: There are about 10 seconds between each GSS failure so basically a 30-second timeout before falling back to LDAP.
I just ran into this issue on my F8 test machine. If the KDC is stopped, but the host that the KDC runs on is up, the timeout it relatively quick as Rob described in comment #3. If the KDC host is completely down, you'll see 3 attempts to contact the KDC, which each fail after what seems to be a 40 second timeout, so basically a 2 minute hang. After the 3 attempts fail, ssh will fallback to other authentication methods: debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug3: Trying to reverse map address 192.168.1.5. debug1: Unspecified GSS failure. Minor code may provide more information Cannot contact any KDC for requested realm debug1: Unspecified GSS failure. Minor code may provide more information Cannot contact any KDC for requested realm debug1: Unspecified GSS failure. Minor code may provide more information debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey
Reopening to discuss if a 2 minute hang is acceptable or not when the KDC host is not reachable.
I should also note that the ConnectTimeout and NumberOfPasswordPrompts have no effect on the amount of time that ssh will hang in this case. It seems to be a krb5 timeout, and possibly a hard-coded number of attempts in ssh.
Some searching turned up two krb5.conf parameters that look like they would help, but I don't know that they are supported in the krb5 packages on Fedora. I tried setting them, but didn't see any change in behavior. Here are the descriptions from the man page of krb5.conf on a NetBSD system: kdc_timeout = time Maximum time to wait for a reply from the kdc, default is 3 seconds. max_retries = number The max number of times to try to contact each KDC. These parameters are to be used in the [libdefaults] section of krb5.conf. Perhaps we need to add support for these parameters to our krb5 packages and then set sane defaults when we configure the krb5.conf?
Nalin say that these parameters are not supported by MIT Kerberos. They may be netbsd specific patches, maybe we need to propose a patch ?
Is this ready to be assigned to me? Have we added a patch to support new parameters (which?), and do they have default values? Which platforms & versions do they relate to?
Added to troubleshooting guide on wiki. Will be incorporated into docbook, probably administrator's guide.
QA Verified on May 27, 2008 (Yi) The link to doc is below http://www.freeipa.com/page/TroubleshootingGuide#SSH_Connections
The problem exists in ipa rhel 6.2 / 6.3 beta. When client outside firewall connecting to server with ssh takes very long time. Or some other situations ẃhen kdc is not available. It works better if IP packages are rejected in firewall. You can test the firewall rules below on client to simulate the issue # test1 # Add "Deny IPA access" rule iptables -I OUTPUT -d ipa.server.ip -j DROP iptables -I OUTPUT -d ipa2.server.ip -j DROP # clear test1 rules # Remove "Deny IPA access" rule iptables -D OUTPUT -d ipa.server.ip -j DROP iptables -D OUTPUT -d ipa2.server.ip -j DROP # test2 # Add "Reject IPA access with icmp" rule iptables -I OUTPUT -d ipa.server.ip -j REJECT --reject-with icmp-host-prohibited iptables -I OUTPUT -d ipa2.server.ip -j REJECT --reject-with icmp-host-prohibited # clear test2 rules # Remove "Reject IPA access with icmp" rule iptables -D OUTPUT -d ipa.server.ip -j REJECT --reject-with icmp-host-prohibited iptables -D OUTPUT -d ipa2.server.ip -j REJECT --reject-with icmp-host-prohibited