First, background note
First heard Kerberos KDC and should be a junior, "Applied Cryptography", was feeling this symmetric key distribution mechanism is better understood than the PKI asymmetric key distribution mechanism. But a few years due to the reality that uses SSL scenario comparison was also in contact with more than (mainly https) so understanding of PKI's actually more than the KDC.
Kinit need to contact the Kerberos impression that only one operator to host a big data platform ssh to another host application notes a specific principle is not very clear, there is no in-depth inquiry. These days one is relatively empty feeling after the second is to explore some lingua franca so, this article can be considered this link to a realization of the document.
In addition, it must first clear Kerberos KDC is a concrete realization of ideas, just as the current digital signature certificate PKI is a concrete realization of the same idea; but they are a few things better, and that their basic ideas become synonymous.
Two, Kerberos + SSH installation configuration
2.1 Kerberos installation configuration
2.1.1 Pre-operation
The current user to sudo password-free. Edit / etc / sudoers file and add the following (ls my current user, change their operation):
ls ALL=(ALL) NOPASSWD: ALL
The domain will be used subsequent / hostname pointing to the local. Edit / etc / hosts writes the following (192.168.220.143 is my current computer IP, into their own; the last ls-virtual-machine is my current host computer name, change your own; in addition if / etc / hosts will be there to resolve the hostname to 127.0.0.1 entry, you should delete it)
127.0.0.1 localhost
192.168.220.143 monarch.example.com monarch krb1.example.com krb1 ls-virtual-machine
2.1.2 Installing Kerberos Service
sudo apt install krb5-admin-server krb5-kdc -y
To confirm a few problems when installing krb5-admin-server (operating system with Kerberos form may be a slight difference, but the meaning is almost all), the following input directly enter.
Specify the default fields, use EXAMPLE.COM:
Default Kerberos version 5 realm? EXAMPLE.COM
The default field to use Kerberos server, use krb1.example.com (front we have 2.1 krb1.example.com also point to the local)
Kerberos servers for your realm: krb1.example.com
The default management server used in the field, as the use of krb1.example.com:
Administrative server for your Kerberos realm: krb1.example.com
2.1.3 Initial Configuration
EXAMPLE.COM using the following command to initialize the field corresponding to the front configuration database, and set a password in this field:
sudo krb5_newrealm
Edit /etc/krb5.conf, targeting [the domain_realm] ganglia, recovered following:
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
Continue Edit /etc/krb5.conf, append the following at the end of the file, set its log file directory:
[logging]
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmin.log
default = FILE:/var/log/kerberos/krb5lib.log
Since the / var / log / kerberos directory does not exist, so we have to put out a log to create directories and files:
sudo mkdir /var/log/kerberos
sudo touch /var/log/kerberos/{krb5kdc,kadmin,krb5lib}.log sudo chmod -R 750 /var/log/kerberos
Finally, to make the above configurations take effect, we need to restart the service:
sudo invoke-rc.d krb5-admin-server restart
sudo invoke-rc.d krb5-kdc restart
2.1.4 Create a policy set
Policy set is a collection of rules, we created here admin / host / service / user four policy set (minlength password length policy is set, minclasses is password element types), as follows:
ls@ls-virtual-machine:~$ sudo kadmin.local Authenticating as principal root/[email protected] with password. kadmin.local: add_policy -minlength 8 -minclasses 3 admin kadmin.local: add_policy -minlength 8 -minclasses 4 host kadmin.local: add_policy -minlength 8 -minclasses 4 service kadmin.local: add_policy -minlength 8 -minclasses 2 user kadmin.local: kadmin.local: quit
2.1.5 Creating an account at a specific set of rules
Which represents the membership user user policy set, ls is the user name (ls is my current user name, into their own); password must be remembered because the account you want to use the password to get tickets:
ls@ls-virtual-machine:~$ sudo kadmin.local Authenticating as principal root/[email protected] with password. kadmin.local: addprinc -policy user ls Enter password for principal "[email protected]": Re-enter password for principal "[email protected]": Principal "[email protected]" created. kadmin.local: kadmin.local: quit
2.2 ssh integrated Kerberos
After the above steps, we have installed the Kerberos, and now to demonstrate how to use ssh to complete kerberos authentication and login.
2.2.1 install ssh
sudo apt install openssh-server openssh-client
2.2.2 Configuring ssh support Kerberos authentication
Edit / etc / ssh / sshd_config, the following are enabled (where the last of the "UsePAM yes" general Enabled):
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIKeyExchange yes
UsePAM yes
Restart ssh configuration to take effect:
sudo invoke-rc.d ssh restart
2.2.3 Creating ssh login rules
service is still our service policy set that you added earlier; host is telnet / rsh / ssh and other services are referred to in the kerberos, monarch.example.com rules applicable hostname:
ls@ls-virtual-machine:~$ sudo kadmin.local Authenticating as principal root/[email protected] with password. kadmin.local: addprinc -policy service -randkey host/monarch.example.com Principal "host/[email protected]" created. kadmin.local: ktadd -k /etc/krb5.keytab -norandkey host/monarch.example.com Entry for principal host/monarch.example.com with kvno 1, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.example.com with kvno 1, encryption type arcfour-hmac added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.example.com with kvno 1, encryption type des3-cbc-sha1 added to keytab WRFILE:/etc/krb5.keytab. Entry for principal host/monarch.example.com with kvno 1, encryption type des-cbc-crc added to keytab WRFILE:/etc/krb5.keytab. kadmin.local: kadmin.local: quit
2.2.4 obtain a user bills
ls is my current user name, into their own; get bills password is set when the rule was created 2.5 password (klist -f to view bills currently exist):
ls@ls-virtual-machine:~$ kinit ls Password for ls@EXAMPLE.COM: ls@ls-virtual-machine:~$ ls@ls-virtual-machine:~$ klist -f Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: ls@EXAMPLE.COM Valid starting Expires Service principal 2019-08-06T15:56:52 2019-08-07T01:56:52 krbtgt/[email protected] renew until 2019-08-07T15:54:39, Flags: FPRIA
2.2.5 Test Log
Use notes using the acquired user (ls) and can host (monarch.example.com) through bills login, no password is required to log as follows:
Third, the principle analysis
Because there are many concepts and he is not sure, understanding may be biased or even wrong, so when reading the required discretion.
3.1 KDC principle
Role: Key Distribution Center KDC, users A, B. KDC retains stored user A, user B communicate symmetric key, user A, user B has communication with the KDC symmetric key.
Desired operation: User A and User B wants to communicate.
Implementation: the user A to the KDC, using K A-KDC encrypted, sending a request like communicate with user B's.
KDC Upon receiving a request, using K A-KDC decryption, generates K A-B , and its use K A-KDC sent to A encrypted using K B-KDC encrypted and sent to B.
After receiving the A and B respectively using K A-KDC and K B-KDC decrypted K A-B .
A use K A-B sends the encrypted message to B.
Note: You can see, in this mode need KDC Key store all communication with the user, and all users only need to store communication KDC Key, Key between the user and the user is dynamically generated and distributed.
3.2 Kerberos process
Role: The authentication server AS, the bill approving server TGS, server DS, the client A; the first two equivalent KDC, the first three are referred to three Kerberos server. Storing the first three symmetric key used for mutual communication, the client does not store any A symmetric key.
Desired operation: A client and server-side DS wants to communicate.
Implementation process: client A to AS, in plain text, obtain a copy of the bill to access the TGS.
AS receives a request, A verification sent username and password, if correct, generates K A-TGS , and use them to generate the password by K a-as encrypted and sent to the A, using K AS-TGS sent encrypted to TGS .
After receipt A also generates a cryptographic K The a-as decryption, TGS use K AS-TGS decryption.
A obtained using K A-TGS , encrypted, to communicate with a TGS request B.
TGS Upon receiving a request, using K A-TGS decrypts, according to his intention, to generate K A-B , and respectively using K A TGS- encrypted and sent to the A, using K B-TGS sent encrypted to B.
After receiving the A and B respectively using K A-TGS and K B-TGS decrypted K A-B .
A use K A-B sends the encrypted message to B.
Description: Kerberos KDC will be split into two AS and TGS service, this benefit is, K A-TGS is no longer valid as K front of a-kdc as long-term effective, when K A-TGS after expired user can enter the password to obtain a new K a-TGS .
3.3 SSH process of Kerberos
Role correspondence: Kerberos Kai What process / service analysis which is not yet TGS AS which is on the first do not understand, SSH server is equivalent to DS, SSH client is equivalent to the client A.
Corresponding to the operation: 2.1.5 Create an account, it is to import account information in the AS database.
2.2.4 kinit ls, is to apply for access to the AS TGS ticket.
2.2.5 When registered, SSH client requesting access only to the TGS SSH server.
3.4 KDC and analysis of the merits of PKI
The final results from the point of view, KDC and PKI have completed the distribution of symmetric keys, that the effect is the same.
From the pre-conditions point of view, first of all intended to remain in the KDC environment requires a specialized service (device), user data (user name, password, or symmetric key) followed by its will to be stored along with subscriber growth and growth in the last the use between the user and the KDC is thus symmetric key may be a problem of non-No.
In sum, we feel KDC applicable to communications between the internal network services, PKI applicable to communications between the external network client and server.
reference:
http://techpubs.spinlocksolutions.com/dklar/kerberos.html#krb-install