From owner-svn-doc-all@FreeBSD.ORG Fri Apr 4 15:48:10 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51D44C22; Fri, 4 Apr 2014 15:48:10 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CCD1E6B; Fri, 4 Apr 2014 15:48:10 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s34FmAiV060794; Fri, 4 Apr 2014 15:48:10 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s34FmAal060793; Fri, 4 Apr 2014 15:48:10 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201404041548.s34FmAal060793@svn.freebsd.org> From: Dru Lavigne Date: Fri, 4 Apr 2014 15:48:10 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44445 - head/en_US.ISO8859-1/books/handbook/security X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Apr 2014 15:48:10 -0000 Author: dru Date: Fri Apr 4 15:48:09 2014 New Revision: 44445 URL: http://svnweb.freebsd.org/changeset/doc/44445 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:21:36 2014 (r44444) +++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml Fri Apr 4 15:48:09 2014 (r44445) @@ -24,15 +24,14 @@ Synopsis - Security, whether physical or virtual, is a topic - so broad that an entire industry has grown up around it. - Hundreds of standard practices have been authored about - how to secure systems and networks, and as a user of &os;, - understanding how to protect against attacks and intruders - is a must. + Security, whether physical or virtual, is a topic so broad + that an entire industry has grown up around it. Hundreds of + standard practices have been authored about how to secure + systems and networks, and as a user of &os;, understanding how + to protect against attacks and intruders is a must. - In this chapter, several fundamentals and techniques will - be discussed. The &os; system comes with multiple layers of + In this chapter, several fundamentals and techniques will be + discussed. The &os; system comes with multiple layers of security, and many more third party utilities may be added to enhance security. @@ -76,9 +75,9 @@ - How to use portaudit to - audit third party software packages installed from the - Ports Collection. + How to use portaudit to audit + third party software packages installed from the Ports + Collection. @@ -91,8 +90,8 @@ - Understand the resource limits database and - how to utilize it to control user resources. + Understand the resource limits database and how to + utilize it to control user resources. @@ -121,11 +120,11 @@ integrity, and availability of information systems. The CIA triad is a bedrock concept of - computer security, customers and end users expect privacy - of their data. They expect orders they place to not be changed - or their information altered behind the scenes. They also - expect access to information at all times. Together they make - up the confidentiality, integrity, and availability of the + computer security, customers and end users expect privacy of + their data. They expect orders they place to not be changed or + their information altered behind the scenes. They also expect + access to information at all times. Together they make up the + confidentiality, integrity, and availability of the system. To protect CIA, security professionals @@ -1070,51 +1069,48 @@ sendmail : PARANOID : denyKerberos can be described as an - identity-verifying proxy system and as a - trusted third-party authentication system. After a user - authenticates with Kerberos, their - communications can be encrypted to assure privacy and data - integrity. + identity-verifying proxy system and as a trusted third-party + authentication system. After a user authenticates with + Kerberos, their communications can be + encrypted to assure privacy and data integrity. The only function of Kerberos is to provide the secure authentication of users on the network. - It does not provide authorization - or auditing functions. It - is recommended that Kerberos be used + It does not provide authorization or auditing functions. It is + recommended that Kerberos be used with other security methods which provide authorization and audit services. The current version of the protocol is version 5, described in RFC 1510. Several free - implementations of this protocol are - available, covering a wide range of operating systems. - MIT - continues to develop their Kerberos - package. It is commonly used in the US as - a cryptography product, and has historically been affected by - US export regulations. In &os;, - MIT Kerberos is - available as the security/krb5 package or - port. Heimdal Kerberos - was explicitly developed outside - of the US to avoid export regulations. The - Heimdal Kerberos distribution is - available as the security/heimdal package - or port, and a minimal installation is included in the base - &os; install. + implementations of this protocol are available, covering a wide + range of operating systems. MIT continues to + develop their Kerberos package. It + is commonly used in the US as a cryptography + product, and has historically been affected by + US export regulations. In &os;, + MIT Kerberos is + available as the security/krb5 package or + port. Heimdal Kerberos was + explicitly developed outside of the US to + avoid export regulations. The Heimdal + Kerberos distribution is available as + the security/heimdal package or port, and a + minimal installation is included in the base &os; + install. This section provides a guide on how to set up Kerberos using the Heimdal - distribution included in &os;. + distribution included in &os;. For purposes of demonstrating a - Kerberos installation, the - name spaces will be as follows: + Kerberos installation, the name + spaces will be as follows: - The DNS domain (zone) - will be The DNS domain (zone) will be + example.org. @@ -1127,8 +1123,8 @@ sendmail : PARANOID : deny Use real domain names when setting up Kerberos, even if it will run - internally. This avoids DNS problems - and assures inter-operation with other + internally. This avoids DNS problems and + assures inter-operation with other Kerberos realms. @@ -1144,18 +1140,18 @@ sendmail : PARANOID : denyKerberos provides. It is the computer that issues Kerberos - tickets. The KDC is considered - trusted by all other computers in the + tickets. The KDC is considered trusted by + all other computers in the Kerberos realm, and thus has heightened security concerns. - While running a KDC - requires few computing resources, a dedicated - machine acting only as a KDC is recommended - for security reasons. + While running a KDC requires few + computing resources, a dedicated machine acting only as a + KDC is recommended for security + reasons. - To begin setting up a KDC, add these lines to - /etc/rc.conf: + To begin setting up a KDC, add these + lines to /etc/rc.conf: kerberos5_server_enable="YES" kadmind5_server_enable="YES" @@ -1173,27 +1169,26 @@ kadmind5_server_enable="YES".example.org = EXAMPLE.ORG - In this example, the - KDC will use the fully-qualified hostname - In this example, the KDC will use the + fully-qualified hostname kerberos.example.org. Add - a CNAME entry to the DNS zone file - if the KDC has a different hostname than - that specified in /etc/krb5.conf. - - For large networks with a properly configured - DNS server, the above example could be - trimmed to: + a CNAME entry to the DNS + zone file if the KDC has a different + hostname than that specified in + /etc/krb5.conf. + + For large networks with a properly configured + DNS server, the above example could be + trimmed to: - [libdefaults] + [libdefaults] default_realm = EXAMPLE.ORG - With the following lines being appended to the - example.org zone - file: + With the following lines being appended to the + example.org zone + file: - _kerberos._udp IN SRV 01 00 88 kerberos.example.org. + _kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. @@ -1201,20 +1196,21 @@ _kerberos IN TXT In order for clients to be able to find the - Kerberos services, the KDC - must have either a fully configured - /etc/krb5.conf or a minimally - configured /etc/krb5.conf - and a properly configured DNS - server. + Kerberos services, the + KDC must have either + a fully configured /etc/krb5.conf or a + minimally configured /etc/krb5.conf + and a properly configured + DNS server. Next, create the Kerberos - database which contains the keys of all principals (users and hosts) encrypted - with a master password. It is not required to remember this - password as it will be stored in - /var/heimdal/m-key. To create the - master key, run kstash and enter a password: + database which contains the keys of all principals (users and + hosts) encrypted with a master password. It is not required + to remember this password as it will be stored in + /var/heimdal/m-key. To create the master + key, run kstash and enter a + password: &prompt.root; kstash Master key: xxxxxxxx @@ -1222,23 +1218,24 @@ Verifying password - Master key: Once the master key has been created, initialize the database using kadmin -l. This option - instructs kadmin to modify the local database files - directly rather than going through the &man.kadmind.8; network - service. This handles the chicken-and-egg problem of trying - to connect to the database before it is created. At the - kadmin prompt, use init to create - the realm's initial database: + instructs kadmin to modify the local + database files directly rather than going through the + &man.kadmind.8; network service. This handles the + chicken-and-egg problem of trying to connect to the database + before it is created. At the kadmin + prompt, use init to create the realm's + initial database: &prompt.root; kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: - Lastly, while still in kadmin, create the first - principal using add. Stick to the default - options for the principal for now, as these can be changed - later with modify. Type - ? at the prompt to see the - available options. + Lastly, while still in kadmin, create + the first principal using add. Stick to + the default options for the principal for now, as these can be + changed later with modify. Type + ? at the prompt to see the available + options. kadmin> add tillman Max ticket life [unlimited]: @@ -1249,12 +1246,12 @@ Verifying password - Password: Next, start the KDC services by running service kerberos start and - service kadmind start. - While there will not be any kerberized daemons - running at this point, it is possible to confirm that the - KDC is functioning by obtaining and - listing a ticket for the principal that was just - created from the command-line of the KDC: + service kadmind start. While there will + not be any kerberized daemons running at this point, it is + possible to confirm that the KDC is + functioning by obtaining and listing a ticket for the + principal that was just created from the command-line of the + KDC: &prompt.user; kinit tillman tillman@EXAMPLE.ORG's Password: @@ -1266,7 +1263,8 @@ Credentials cache: FILE:/tmp/krb5cc_500 Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG - The temporary ticket can be revoked when the test is finished: + The temporary ticket can be revoked when the test is + finished: &prompt.user; kdestroy @@ -1283,23 +1281,21 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt To configure a server to use Kerberos authentication, copy /etc/krb5.conf from the - KDC to the server in a secure - fashion, such as &man.scp.1;, or physically via removable - media. + KDC to the server in a secure fashion, such + as &man.scp.1;, or physically via removable media. Next, create /etc/krb5.keytab on the - server. - This is the major difference between a server providing - Kerberos enabled daemons and a - workstation: the server must have a - keytab. This file contains the - server's host key, which allows it and the - KDC to verify each others identity. It - must be transmitted to the server in a secure fashion, as - the security of the server can be broken if the key is made - public. Typically, the keytab is transferred - to the server using kadmin. This is handy because the - host principal, the KDC end of the + server. This is the major difference between a server + providing Kerberos enabled daemons + and a workstation: the server must have a + keytab. This file contains the server's + host key, which allows it and the KDC to + verify each others identity. It must be transmitted to the + server in a secure fashion, as the security of the server can + be broken if the key is made public. Typically, the + keytab is transferred to the server using + kadmin. This is handy because the host + principal, the KDC end of the krb5.keytab, is also created using kadmin. @@ -1308,17 +1304,17 @@ Aug 27 15:37:58 Aug 28 01:37:58 krbtgt kadmind.acl. See the section titled Remote administration in info heimdal for details on designing access control - lists. Instead of enabling remote kadmin access, the - administrator can securely connect to the + lists. Instead of enabling remote kadmin + access, the administrator can securely connect to the KDC via the local console or &man.ssh.1;, and perform administration locally using kadmin -l. After installing /etc/krb5.conf, use add --random-key from the - Kerberos server. This adds - the server's host principal. Then, use ext - to extract the server's host principal to its own keytab: + Kerberos server. This adds the + server's host principal. Then, use ext to + extract the server's host principal to its own keytab: &prompt.root; kadmin kadmin> add --random-key host/myserver.example.org @@ -1350,11 +1346,11 @@ kadmin> exitAt this point, the server can communicate with the KDC using - krb5.conf and it can prove its - own identity with krb5.keytab. It is now + krb5.conf and it can prove its own + identity with krb5.keytab. It is now ready for the Kerberos services to - be enabled. For this example, the &man.telnetd.8; service - is enabled in /etc/inetd.conf and + be enabled. For this example, the &man.telnetd.8; service is + enabled in /etc/inetd.conf and &man.inetd.8; has been restarted with service inetd restart: @@ -1376,36 +1372,34 @@ kadmin> exitTo configure a client to use Kerberos, securely copy - /etc/krb5.conf - to the client computer from the - KDC. + /etc/krb5.conf to the client computer + from the KDC. Test the client by using kinit, - klist, and kdestroy from the client to obtain, - show, and then delete an existing ticket for the principal. - Kerberos applications - should also be able to connect to + klist, and kdestroy from + the client to obtain, show, and then delete an existing ticket + for the principal. Kerberos + applications should also be able to connect to Kerberos enabled servers. If that does not work but obtaining a ticket does, the problem is likely with the server and not with the client or the KDC. When testing a Kerberized application, try using a packet - sniffer such as tcpdump to confirm that the password - is not sent in the clear. + sniffer such as tcpdump to confirm that the + password is not sent in the clear. - Various Kerberos - client applications are available. - &os; installs telnetd as the only + Various Kerberos client + applications are available. &os; installs + telnetd as the only Kerberos enabled service. The Heimdal package or port installs Kerberos enabled versions of ftpd, rshd, - rcp, rlogind, and - a few other less common programs. The MIT - port contains a full suite of - Kerberos client - applications. + rcp, rlogind, and a few + other less common programs. The MIT port + contains a full suite of Kerberos + client applications. .k5login @@ -1429,8 +1423,8 @@ kadmin> exitThe .k5login and .k5users files, placed in a user's home directory, can be used to solve this problem. For example, if - the following .k5login is - placed in the home directory of .k5login is placed in the + home directory of webdevelopers, both principals listed will have access to that account without requiring a shared password.: @@ -1445,22 +1439,22 @@ jdoe@example.org <acronym>MIT</acronym> Differences - The major difference between the MIT and - Heimdal implementations is that kadmin has a different, but - equivalent, set of commands and uses a different protocol. - If the KDC is MIT, the - Heimdal version of kadmin cannot be used to administer - the KDC remotely, and vice versa. + The major difference between the MIT + and Heimdal implementations is that kadmin + has a different, but equivalent, set of commands and uses a + different protocol. If the KDC is + MIT, the Heimdal version of + kadmin cannot be used to administer the + KDC remotely, and vice versa. Client applications may also use slightly different - command line options to accomplish the same tasks. - Following the instructions at - Kerberos Kerberos http://web.mit.edu/Kerberos/www/ is recommended. Be careful of path issues: the MIT port installs into - /usr/local/ by default, and the - &os; system applications run instead of the + /usr/local/ by default, and the &os; + system applications run instead of the MIT versions if PATH lists the system directories first. @@ -1469,10 +1463,10 @@ jdoe@example.org security/krb5 port, be sure to read /usr/local/share/doc/krb5/README.FreeBSD installed by the port to understand why logins via - telnetd and klogind behave - somewhat oddly. Correcting the incorrect permissions - on cache file behavior requires that the - login.krb5 binary be used for + telnetd and klogind + behave somewhat oddly. Correcting the incorrect + permissions on cache file behavior requires that + the login.krb5 binary be used for authentication so that it can properly change ownership for the forwarded credentials. @@ -1494,12 +1488,12 @@ kadmind5_server_enable="YES"When configuring and troubleshooting Kerberos, keep the following points in mind: - + - When using either Heimdal or - MIT - Kerberos, ensure that the PATH lists the + When using either Heimdal or MIT + Kerberos, ensure that the + PATH lists the Kerberos versions of the client applications before the system versions. @@ -1536,8 +1530,9 @@ kadmind5_server_enable="YES"KDC do not set the permissions for ksu to be setuid root. This means that - ksu does not work. This is a permissions problem, not a - KDC error. + ksu does not work. This is a + permissions problem, not a KDC + error. @@ -1545,50 +1540,50 @@ kadmind5_server_enable="YES"Kerberos, to allow a principal to have a ticket life longer than the default ten hours, use modify_principal at the - &man.kadmin.8; prompt to change the maxlife of both the - principal in question and the maxlife of both the principal in + question and the krbtgt principal. The principal can then use kinit -l to request a ticket with a longer lifetime. - When running a packet sniffer on the - KDC to aid in troubleshooting while - running kinit from a workstation, the Ticket - Granting Ticket (TGT) is sent - immediately, even before the - password is typed. This is because the - Kerberos server freely - transmits a TGT to any unauthorized - request. However, every TGT is - encrypted in a key derived from the user's password. - When a user types their password, it is not sent to the - KDC, it is instead used to decrypt - the TGT that kinit already - obtained. If the decryption process results in a valid - ticket with a valid time stamp, the user has valid - Kerberos credentials. - These credentials include a session key for - establishing secure communications with the - Kerberos server in the - future, as well as the actual TGT, - which is encrypted with the - Kerberos server's own key. - This second layer of encryption allows the - Kerberos server to verify - the authenticity of each TGT. + When running a packet sniffer on the + KDC to aid in troubleshooting while + running kinit from a workstation, the + Ticket Granting Ticket (TGT) is sent + immediately, even before the password is typed. This is + because the Kerberos server + freely transmits a TGT to any + unauthorized request. However, every + TGT is encrypted in a key derived from + the user's password. When a user types their password, it + is not sent to the KDC, it is instead + used to decrypt the TGT that + kinit already obtained. If the + decryption process results in a valid ticket with a valid + time stamp, the user has valid + Kerberos credentials. These + credentials include a session key for establishing secure + communications with the + Kerberos server in the future, + as well as the actual TGT, which is + encrypted with the Kerberos + server's own key. This second layer of encryption allows + the Kerberos server to verify + the authenticity of each TGT. - To use long ticket lifetimes when - using OpenSSH to connect to the + To use long ticket lifetimes when using + OpenSSH to connect to the machine where the ticket is stored, make sure that Kerberos is set to no in - /etc/ssh/sshd_config. Otherwise, tickets will be - deleted at log out. + /etc/ssh/sshd_config. Otherwise, + tickets will be deleted at log out. @@ -1614,104 +1609,106 @@ kadmind5_server_enable="YES" - Mitigating <application>Kerberos</application> Limitations + Mitigating <application>Kerberos</application> + Limitations Kerberos5 limitations and shortcomings - Since Kerberos is an all or - nothing approach, every service enabled on the network must either be modified - to work with Kerberos or be - otherwise secured against network attacks. This is to prevent - user credentials from being stolen and re-used. An example is when - Kerberos is - enabled on all remote shells but the non-Kerberized - POP3 mail server sends passwords in - plain text. - - Kerberos is intended for - single-user workstations. In a multi-user environment, - Kerberos is less secure as it - stores the tickets in /tmp, - which is readable by all users. If a user is sharing a - computer, it is possible that the user's - tickets can be stolen or copied by another user. - - This can be overcome with kinit -c - or, preferably, the - KRB5CCNAME environment variable. Storing - the ticket in the user's home directory and using file - permissions are commonly used to mitigate this - problem. - - The KDC is a single point of failure. By design, the - KDC must be as secure - as its master password database. The KDC - should have absolutely no other services running on it and - should be physically secure. The danger is high because - Kerberos stores all passwords - encrypted with the same master key which is - stored as a file on the KDC. - - A compromised master key is not quite as bad as one - might fear. The master key is only used to encrypt the - Kerberos database and as a seed - for the random number generator. As long as access to the - KDC is secure, an attacker cannot do much - with the master key. - - If the KDC is - unavailable, network services are unusable as authentication - cannot be performed. This can be alleviated with a single - master KDC and one or more slaves, and - with careful implementation of secondary or fall-back - authentication using PAM. - - Kerberos allows users, hosts - and services to authenticate between themselves. It does - not have a mechanism to authenticate the - KDC to the users, hosts, or services. - This means that a trojanned kinit could record all - user names and passwords. File system integrity checking - tools like security/tripwire can - alleviate this. + Since Kerberos is an all or + nothing approach, every service enabled on the network must + either be modified to work with + Kerberos or be otherwise secured + against network attacks. This is to prevent user credentials + from being stolen and re-used. An example is when + Kerberos is enabled on all remote + shells but the non-Kerberized POP3 mail + server sends passwords in plain text. + + Kerberos is intended for + single-user workstations. In a multi-user environment, + Kerberos is less secure as it + stores the tickets in /tmp, which is + readable by all users. If a user is sharing a computer, it is + possible that the user's tickets can be stolen or copied by + another user. + + This can be overcome with kinit -c or, + preferably, the KRB5CCNAME environment + variable. Storing the ticket in the user's home directory and + using file permissions are commonly used to mitigate this + problem. + + The KDC is a single point of failure. + By design, the KDC must be as secure as its + master password database. The KDC should + have absolutely no other services running on it and should be + physically secure. The danger is high because + Kerberos stores all passwords + encrypted with the same master key which is stored as a file + on the KDC. + + A compromised master key is not quite as bad as one might + fear. The master key is only used to encrypt the + Kerberos database and as a seed for + the random number generator. As long as access to the + KDC is secure, an attacker cannot do much + with the master key. + + If the KDC is unavailable, network + services are unusable as authentication cannot be performed. + This can be alleviated with a single master + KDC and one or more slaves, and with + careful implementation of secondary or fall-back + authentication using PAM. + + Kerberos allows users, hosts + and services to authenticate between themselves. It does not + have a mechanism to authenticate the + KDC to the users, hosts, or services. This + means that a trojanned kinit could record + all user names and passwords. File system integrity checking + tools like security/tripwire can + alleviate this. - Access Issues with Kerberos and <command>ssh</command> + Access Issues with Kerberos and + <command>ssh</command> &man.ssh.1; - Kerberos is an - excellent authentication protocol, but there are bugs in the - kerberized versions of telnet and rlogin that + Kerberos is an excellent authentication protocol, but + there are bugs in the kerberized versions of + telnet and rlogin that make them unsuitable for dealing with binary streams. By default, Kerberos does not encrypt a session unless - is used, whereas ssh encrypts - everything. + is used, whereas ssh + encrypts everything. - While ssh works well, it forwards encryption keys - by default. This introduces a security risk to a user who - uses ssh to access an insecure machine from a secure - workstation. The keys themselves are not exposed, but - ssh installs a forwarding port for the duration of the - login. If an attacker has broken - root on - the insecure machine, he can utilize that port to gain access - to any other machine that those keys unlock. - - It is recommended that ssh is used in combination - with Kerberos whenever possible for staff logins as it - can be compiled with Kerberos support. This - reduces reliance on potentially exposed SSH - keys while protecting passwords via Kerberos. Keys should - only be used for automated tasks from secure machines as this - is something that Kerberos is unsuited to. It is recommended - to either turn off key-forwarding in the - SSH configuration, or to make use - of from=IP/DOMAIN in + While ssh works well, it forwards + encryption keys by default. This introduces a security risk + to a user who uses ssh to access an + insecure machine from a secure workstation. The keys + themselves are not exposed, but ssh + installs a forwarding port for the duration of the login. If + an attacker has broken root on the insecure machine, + he can utilize that port to gain access to any other machine + that those keys unlock. + + It is recommended that ssh is used in + combination with Kerberos whenever possible for staff logins + as it can be compiled with Kerberos support. This reduces + reliance on potentially exposed SSH keys + while protecting passwords via Kerberos. Keys should only be + used for automated tasks from secure machines as this is + something that Kerberos is unsuited to. It is recommended to + either turn off key-forwarding in the + SSH configuration, or to make use of + from=IP/DOMAIN in authorized_keys to make the key only usable to entities logging in from specific machines.