Bug 430033

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