我试图为我的 CDH 4.3 （通过Cloudera Manager）测试台启用Kerberos。因此，在WebUI中将身份验证从Simple更改为Kerberos后，我无法执行任何hadoop操作，如下所示。无论如何都要明确指定密钥表吗？
[root@host-dn15 ~]# su - hdfs
-bash-4.1$ hdfs dfs -ls /
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
13/09/10 08:15:35 ERROR security.UserGroupInformation: PriviledgedActionException as:hdfs (auth:KERBEROS) cause:java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
ls: Failed on local exception: java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]; Host Details : local host is: "host-dn15.hadoop.com/192.168.10.227"; destination host is: "host-dn15.hadoop.com":8020;
-bash-4.1$ kdestroy
-bash-4.1$ kinit
Password for hdfs@HADOOP.COM:
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM
Valid starting Expires Service principal
09/10/13 08:20:31 09/11/13 08:20:31 krbtgt/HADOOP.COM@HADOOP.COM
renew until 09/10/13 08:20:31
-bash-4.1$ klist -e
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM
Valid starting Expires Service principal
09/10/13 08:20:31 09/11/13 08:20:31 krbtgt/HADOOP.COM@HADOOP.COM
renew until 09/10/13 08:20:31, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
-bash-4.1$
所以我仔细研究了namenode日志，
2013-09-10 10:02:06,085 INFO org.apache.hadoop.ipc.Server: IPC Server listener on 8022: readAndProcess threw exception javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)] from client 10.132.100.228. Count of bytes read: 0
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]
JCE策略文件已安装在所有节点上。
[root@host-dn15 security]# sha256sum ./local_policy.jar
4a5c8f64107c349c662ea688563e5cd07d675255289ab25246a3a46fc4f85767 ./local_policy.jar
[root@host-dn15 security]# sha256sum ./US_export_policy.jar
b800fef6edc0f74560608cecf3775f7a91eb08d6c3417aed81a87c6371726115 ./US_export_policy.jar
[root@host-dn15 security]# sha256sum ./local_policy.jar.bak
7b26d0e16722e5d84062240489dea16acef3ea2053c6ae279933499feae541ab ./local_policy.jar.bak
[root@host-dn15 security]# sha256sum ./US_export_policy.jar.bak
832133c52ed517df991d69770f97c416d2e9afd874cb4f233a751b23087829a3 ./US_export_policy.jar.bak
[root@host-dn15 security]#
领域中的校长名单。
kadmin: listprincs
HTTP/host-dn15.hadoop.com@HADOOP.COM
HTTP/host-dn16.hadoop.com@HADOOP.COM
HTTP/host-dn17.hadoop.com@HADOOP.COM
K/M@HADOOP.COM
cloudera-scm/admin@HADOOP.COM
hbase/host-dn15.hadoop.com@HADOOP.COM
hbase/host-dn16.hadoop.com@HADOOP.COM
hbase/host-dn17.hadoop.com@HADOOP.COM
hdfs/host-dn15.hadoop.com@HADOOP.COM
hdfs/host-dn16.hadoop.com@HADOOP.COM
hdfs/host-dn17.hadoop.com@HADOOP.COM
hdfs@HADOOP.COM
hue/host-dn15.hadoop.com@HADOOP.COM
host-dn16/hadoop.com@HADOOP.COM
kadmin/admin@HADOOP.COM
kadmin/changepw@HADOOP.COM
kadmin/host-dn15.hadoop.com@HADOOP.COM
krbtgt/HADOOP.COM@HADOOP.COM
mapred/host-dn15.hadoop.com@HADOOP.COM
mapred/host-dn16.hadoop.com@HADOOP.COM
mapred/host-dn17.hadoop.com@HADOOP.COM
root/admin@HADOOP.COM
root@HADOOP.COM
zookeeper/host-dn15.hadoop.com@HADOOP.COM
kadmin: exit
[root@host-dn15 ~]#
导出hdfs的keytab并用于kinit。
-bash-4.1$ kinit -kt ./hdfs.keytab hdfs
-bash-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_494
Default principal: hdfs@HADOOP.COM
Valid starting Expires Service principal
09/10/13 09:49:42 09/11/13 09:49:42 krbtgt/HADOOP.COM@HADOOP.COM
renew until 09/10/13 09:49:42
一切都变得徒劳无功。有什么想法??
非常感谢，
答案 0 :(得分：2)
我遇到了一个问题，我有一个Kerberized CDH集群，即使有一个有效的Kerberos票证，我也无法从命令行运行任何hadoop命令。
注意： 写完这个答案后，我在http://sarastreeter.com/2016/09/26/resolving-hadoop-problems-on-kerberized-cdh-5-x/写了一篇博客文章。请分享！
即使使用有效的票证，也会失败：
$ hadoop fs -ls /
WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
这是我学到的以及我最终解决问题的方法。在可能的情况下，我已将Cloudera doc链接到当前版本，但某些文档似乎仅适用于旧版本。
请注意，问题归结为配置问题，但Kerberos本身和Cloudera Manager都已正确安装。我在搜索答案时遇到的许多问题都归结为Kerberos或Hadoop安装不正确。我发生的问题即使Hadoop和Kerberos都正常运行，但它们没有配置为正常协同工作。
从您尝试执行hadoop命令的用户处执行klist。
$ sudo su - myuser
$ klist
如果您没有票，则会打印：
klist: Credentials cache file '/tmp/krb5cc_0' not found
如果您尝试在没有故障单的情况下执行hadoop命令，则设计会出现GSS INITIATE FAILED错误：
WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
换句话说，这不是安装问题。如果这是您的情况，请查看：
Cloudera的默认安装对hadoop命令的执行有用户和组限制，包括对某些用户的特定禁止（http://www.cloudera.com/documentation/enterprise/5-6-x/PDF/cloudera-security.pdf第57页上的更多内容）。
有几个属性可以解决这个问题，包括将hdfs的超级组设置为字符串supergroup而不是hdfs，dfs_permissions enabled属性设置为false by默认（hadoop user file permissions），uid超过1000的用户被禁止。
其中任何一个都可能是一个因素，对我而言，禁用了。在banned.users属性中列出了HDFS。
特别是对于用户HDFS，如果您尝试使用它来执行hadoop命令，请确保已从hdfs-site.xml配置中的banned.users配置属性中删除了hdfs。
1) UNPRIVILEGED USER AND WRITE PERMISSIONS
Cloudera推荐的执行Hadoop命令的方法是创建一个非特权用户和匹配的主体，而不是使用hdfs用户。问题是该用户还需要自己的/user目录，并且可能会在/ user目录中遇到写权限错误。如果您的非特权用户在/user中没有目录，则可能导致WRITE权限被拒绝错误。
2) DATANODE PORTS AND DATA DIR PERMISSIONS
另一个相关问题是Cloudera在非kerberized集群上将dfs.datanode.data.dir设置为750，但在kerberized集群上需要700。如果设置了错误的dir权限，Kerberos安装将失败。数据节点的端口也必须设置为1024以下的值，建议HTTP端口为1006，Datanode端口为1004。
Datanode目录http://www.cloudera.com/documentation/enterprise/5-6-x/topics/cdh_ig_hdfs_cluster_deploy.html
Datanode端口 3) SERVICE-SPECIFIC CONFIGURATION TASKS
在安全文档的第60页，有一些步骤可以解决Hadoop服务问题。确保你做到了这些！
的 MapReduce的$ sudo -u hdfs hadoop fs -chown mapred:hadoop ${mapred.system.dir}
$ sudo -u hdfs hadoop fs -chown -R hbase ${hbase.rootdir}
$ sudo -u hdfs hadoop fs -chown hive /user/hive
$ rm -rf ${yarn.nodemanager.local-dirs}/usercache/*
所有这些步骤除了YARN之外都可以随时发生。 YARN的步骤必须在安装Kerberos之后进行，因为它正在执行的操作是删除非kerberized YARN数据的用户缓存。在Kerberos安装后运行mapreduce时，应使用Kerberized用户缓存数据填充它。
YARN用户缓存YARN Application exited with exitCode: -1000 Not able to initialize user directories
1) SHORT NAME RULES MAPPING
Kerberos主体是＆＃34;映射＆＃34;到OS级服务用户。例如，hdfs / WHATEVER @ REALM映射到服务用户＆＃39; hdfs＆＃39;在您的操作系统中，仅因为Hadoop核心站点中设置了名称映射规则。如果没有名称映射，Hadoop将不知道哪个用户通过哪个主体进行了身份验证。
如果您使用应映射到hdfs的主体，请确保主体名称根据这些Hadoop规则正确解析为hdfs。
不可（默认情况下具有名称映射规则）
（默认情况下没有名称映射规则）
＆＃34;坏＆＃34;除非您添加规则以适应它，否则示例将无效
名称规则映射http://www.cloudera.com/documentation/archive/cdh/4-x/4-5-0/CDH4-Security-Guide/cdh4sg_topic_19.html）
2) KEYTAB AND PRINCIPAL KEY VERSION NUMBERS MUST MATCH
密钥版本号（KVNO）是正在使用的密钥的版本（就好像你有一把房子钥匙然后改变了门上的锁，所以它使用了一把新钥匙，旧的钥匙不再使用好的）。 keytab和principal都有一个KVNO，版本号必须匹配。
默认情况下，当您使用ktadd或xst将主体导出到keytab时，它会更改keytab版本号，但不会更改主体的KVNO。所以你最终可能会意外地造成不匹配。
将主体导出到密钥表时，将-norandkey与kadmin或kadmin.local一起使用，以避免更新密钥表编号并创建KVNO不匹配。
通常，每当主体发出身份验证问题时，请务必检查主体和密钥表的KVNO是否匹配：
的 主要$ kadmin.local -q 'getprinc myprincipalname'
$ klist -kte mykeytab
1) JAVA VERSION MISMATCH WITH JCE JARS
Hadoop需要安装Java安全JCE Unlimited Strength jar才能对Kerberos使用AES-256加密。 Hadoop和Kerberos都需要访问这些jar。这是一个安装问题，但它很容易被忽略，因为你可以认为你真的没有安装安全罐。
要检查的JCE配置：$JAVA_HOME/jre/lib/security $JAVA_HOME中是否有/etc/hadoop/conf/hadoop-env.sh的导出语句到JAVA_HOME 如果Hadoop设置错误rpm -qa | grep krb5，则会失败并且＆＃34; GSS INITIATE FAILED＆＃34;。如果罐子不在正确的位置，Kerberos将无法找到它们，并且会给出一个错误，它不支持AES-256加密类型（不支持的ENCTYPE）。
http://www.cloudera.com/documentation/enterprise/5-5-x/topics/cm_sg_s2_jce_policy.html
对JCE Jars进行故障排除Cloudera在http://www.cloudera.com/documentation/archive/cdh/3-x/3u6/CDH3-Security-Guide/cdh3sg_topic_14_2.html记录了一个问题，其中必须在发出hadoop命令之前续订票证。这仅适用于Oracle JDK 6 Update 26或更早版本以及MIT Kerberos发行版的1.8.1或更高版本的软件包。
要检查软件包，请在CentOS / RHEL上执行aptitude search krb5 -F "%c %p %d %V"或在Debian / Ubuntu上执行kinit -R。
按照惯例做一个普通的kinit，然后执行$ kinit -kt mykeytab myprincipal
$ kinit -R
强制更新票证。
krb5.conf最后，我实际上遇到的问题无法在任何地方找到......
Kerberos有两个重要的配置文件，krb5.conf和kdc.conf。这些是krb5kdc服务和KDC数据库的配置。我的问题是default_ccache_name = KEYRING:persistent:%{uid}文件有一个属性：
kinit。
这将我的缓存名称设置为KEYRING：persistent和user uid（解释https://web.mit.edu/kerberos/krb5-1.13/doc/basic/ccache_def.html）。当我做了一个kinit时，它在/ tmp中创建了票证，因为缓存名称在别处被设置为/ tmp。 Cloudera服务使用/ var / run / cloudera-scm-agent / process中运行时生成的文件获取身份验证，这些文件都会在执行/tmp之前导出缓存名称环境变量（KRB5CCNAME）。这就是为什么Cloudera可以获得门票，但我的hadoop用户无法获得门票。
解决方法是从krb5.conf中删除设置default_ccache_name的行并允许kinit在{{1}}中存储凭据，这是MIT Kerberos默认值DEFCCNAME（记录在https://web.mit.edu/kerberos/krb5-1.13/doc/mitK5defaults.html#paths）。
https://www.cloudera.com/documentation/enterprise/5-6-x/topics/cm_sg_intro_kerb.html。
高级疑难解答http://www.cloudera.com/documentation/enterprise/5-6-x/PDF/cloudera-security.pdf，从第48页开始。