Неверный принципал в запросе (SSH/ GSSAPI/Kerberos/Debian)
Я установил две виртуальные машины в "внутренней" (в смысле VirtualBox) сети, одна из которых является DNS-сервером (dns1.example.com), а другая - административным сервером KDC и Kerberos (kdc.example.com). По умолчанию и единственной областью является EXAMPLE.COM. Обе машины используют только что установленный Debian Squeeze.
Проблема: я могу войти через ssh на kdc.example.com с kdc.example.com, но не могу войти через ssh с dns1.example.com.
На kdc.example.com sshd в режиме отладки говорит:
debug1: Unspecified GSS failure. Minor code may provide more information
Wrong principal in request
debug1: Got no client credentials
debug3: mm_request_send entering: type 41
debug3: mm_request_receive entering
debug1: userauth-request for user tom service ssh-connection method gssapi-with-mic
debug1: attempt 2 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
debug1: userauth-request for user tom service ssh-connection method gssapi-with-mic
debug1: attempt 3 failures 1
debug2: input_userauth_request: try method gssapi-with-mic
в этот момент у клиента запрашивается пароль. Файл tcpdump, обработанный Wireshark, показывает, что произошел некоторый обмен зашифрованными пакетами, но я не могу вычесть больше, поскольку они, ну, в общем, зашифрованы:). После 2 дней поисков я застрял и был бы признателен за любую помощь.
Еще больше я буду признателен за любые советы / ссылки / советы по общей стратегии отладки конфигурации, когда речь заходит о Kerberos и его друзьях. Например, у меня нет идей, где искать, что не так с "Неправильным принципалом", и что это за принцип, который сервер получает вместо правильного. Что-то подсказывает мне, что настоящие приключения еще впереди:).
Ниже приведены конфиги и диагностические выводы. Надеюсь, я ничего не забыл.
kdc:~# cat /etc/krb5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 750,88
[realms]
EXAMPLE.COM = {
database_name = /var/lib/krb5kdc/principal
admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab
acl_file = /etc/krb5kdc/kadm5.acl
key_stash_file = /etc/krb5kdc/stash
kdc_ports = 750,88
max_life = 10h 0m 0s
max_renewable_life = 7d 0h 0m 0s
master_key_type = des3-hmac-sha1
supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3
default_principal_flags = +preauth
}
kdc:~# kadmin.local -q 'listprincs'
Authenticating as principal root/admin@EXAMPLE.COM with password.
K/M@EXAMPLE.COM
host/dns1.example.com@EXAMPLE.COM
host/kdc.example.com@EXAMPLE.COM
host/localhost@EXAMPLE.COM
host/www.example.com@EXAMPLE.COM
kadmin/admin@EXAMPLE.COM
kadmin/changepw@EXAMPLE.COM
kadmin/history@EXAMPLE.COM
kadmin/kdc.example.com@EXAMPLE.COM
krbtgt/EXAMPLE.COM@EXAMPLE.COM
root/admin@EXAMPLE.COM
tom@EXAMPLE.COM
kdc:~# cat /etc/ssh/sshd_config |grep '^[^#]'
Port 22
ListenAddress 172.16.3.3
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPIKeyExchange yes
GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes
/etc/krb5.conf идентичен как для kdc, так и для dns1.
dns1:~$ cat /etc/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
forwardable = true
[realms]
EXAMPLE.COM={
admin_server = kdc.example.com
}
[domain_realm]
example.com = EXAMPLE.COM
.example.com = EXAMPLE.COM
[logging]
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmin.log
default = FILE:/var/log/krb5lib.log
TGT является пересылаемым. На клиенте ssh:
dns1:~$ klist -f
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: tom@EXAMPLE.COM
Valid starting Expires Service principal
01/03/12 20:00:03 01/04/12 06:00:03 krbtgt/EXAMPLE.COM@EXAMPLE.COM
renew until 01/04/12 20:00:00, Flags: FRIA
01/03/12 20:00:21 01/04/12 06:00:03 host/kdc.example.com@EXAMPLE.COM
renew until 01/04/12 20:00:00, Flags: FRAT
Keytab тоже вроде бы в порядке:
dns1:~# klist -k
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
5 host/dns1.example.com@EXAMPLE.COM
5 host/dns1.example.com@EXAMPLE.COM
5 host/dns1.example.com@EXAMPLE.COM
5 host/dns1.example.com@EXAMPLE.COM
DNS (в т.ч. PTR, TXT, SRV) работает как надо.
dns1:~# cat /var/cache/bind/db.example.com
$ORIGIN example.com.
$TTL 86400
@ IN SOA dns1.example.com. root.example.com. (
2012010301 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS dns1.example.com.
dns1 IN A 172.16.3.2
www IN A 172.16.3.8
mail IN A 172.16.3.9
fed IN A 172.16.3.100
kdc IN A 172.16.3.3
;kds IN A 172.16.3.4
_kerberos TXT "EXAMPLE.COM"
krb IN CNAME kdc
_kerberos._udp SRV 0 0 88 kdc
_kerberos-master._udp SRV 0 0 88 kdc
_kerberos-adm._tcp SRV 0 0 749 kdc
_kpasswd._udp SRV 0 0 464 kdc
dns1:~# cat /var/cache/bind/db.3.16.172.in-addr.arpa
$ORIGIN 3.16.172.in-addr.arpa.
$TTL 86400
@ IN SOA dns1.example.com. root.example.com. (
2012010102 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL
;
@ IN NS dns1.example.com.
2 IN PTR dns1.example.com.
3 IN PTR kdc.example.com.
8 IN PTR example.com.
9 IN PTR mail.example.com.
3 ответа
Нашел это, пока Гуглил точно такую же ошибку на новой сборке сервера - указал мне в правильном направлении:)
В моем случае у меня был неправильный обратный DNS - когда я обновил это и очистил кеширующие кэши серверов имен, это сработало.
Я должен быть более внимательным. В /etc/hosts осталась строка, разрешающая 127.0.0.1 в FQDN (теперь закомментирована):
kdc:~$ cat /etc/hosts
127.0.0.1 localhost
#127.0.0.1 kdc.example.com kdc
172.16.3.3 kdc.example.com kdc
После удаления связанных принципалов из БД и таблицы ключей и перезапуска обеих виртуальных машин все работает как нужно. Уффф...
Попробуйте это ниже.
редактировать /etc/ssh/sshd_config
найти PermitRootLogin нет
изменить PermitRootLogin => да
команда> /etc/init.d/sshd restart