Bug 598673 - GSSAPIStrictAcceptorCheck no should be the default in sshd
Summary: GSSAPIStrictAcceptorCheck no should be the default in sshd
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: openssh   
(Show other bugs)
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Jan F. Chadima
QA Contact: BaseOS QE Security Team
Depends On:
TreeView+ depends on / blocked
Reported: 2010-06-01 20:10 UTC by Daniel Walsh
Modified: 2010-06-07 09:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-07 09:12:16 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Daniel Walsh 2010-06-01 20:10:42 UTC
Description of problem:

This check being on was causing ssh testing with kerberos to break.  The kerberos library would prevent me from logging in if the servtab entry was not correct.

Comment 2 RHEL Product and Program Management 2010-06-02 18:25:56 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Nalin Dahyabhai 2010-06-02 18:29:25 UTC
On second thought, if a less careful admin stored keys for other services in
the same keytab file that sshd consulted, then a modified client could use
tickets for one of those other services to log in through sshd.

So we mightn't want to do this if sshd isn't also verifying that the server name is "host@..." (or we can just assume that the admin's not going to put keys for non-"host" services in /etc/krb5.keytab).

Comment 4 Jan F. Chadima 2010-06-07 09:12:16 UTC
I prefer test the settings which may security influence in fedora before deployment in rhel.

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