This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 430033 - ssh does not time out if kdc is unavailable
ssh does not time out if kdc is unavailable
Status: CLOSED CURRENTRELEASE
Product: freeIPA
Classification: Community
Component: ipa-server (Show other bugs)
1.0
All Linux
low Severity low
: ---
: ---
Assigned To: David O'Brien
Chandrasekar Kannan
: Reopened
Depends On:
Blocks: freeipa10 429034
  Show dependency treegraph
 
Reported: 2008-01-24 02:15 EST by Chandrasekar Kannan
Modified: 2015-01-04 18:30 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-12 00:42:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Chandrasekar Kannan 2008-01-24 02:15:08 EST
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.
Comment 3 Rob Crittenden 2008-02-27 16:48:40 EST
Works for me on a Fedora 7 client:

% kdestroy
% kinit admin

stop KDC on IPA server

% slogin -v admin@ipa.example.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@ipa.example.com's password: 

There are about 10 seconds between each GSS failure so basically a 30-second
timeout before falling back to LDAP.
Comment 4 Nathan Kinder 2008-02-28 01:58:27 EST
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
Comment 5 Nathan Kinder 2008-02-28 01:59:28 EST
Reopening to discuss if a 2 minute hang is acceptable or not when the KDC host
is not reachable.
Comment 6 Nathan Kinder 2008-02-28 02:11:01 EST
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.
Comment 7 Nathan Kinder 2008-04-23 11:27:26 EDT
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?
Comment 8 Simo Sorce 2008-04-25 14:07:45 EDT
Nalin say that these parameters are not supported by MIT Kerberos.
They may be netbsd specific patches, maybe we need to propose a patch ?
Comment 9 David O'Brien 2008-05-16 07:22:46 EDT
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?
Comment 10 David O'Brien 2008-05-20 20:37:28 EDT
Added to troubleshooting guide on wiki. Will be incorporated into docbook,
probably administrator's guide.
Comment 11 Yi Zhang 2008-05-27 13:27:33 EDT
QA Verified on May 27, 2008 (Yi)

The link to doc is below
http://www.freeipa.com/page/TroubleshootingGuide#SSH_Connections
Comment 12 Taunus 2012-06-12 02:29:42 EDT
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

Note You need to log in before you can comment on or make changes to this bug.