11.4.1.1. Infrastructure
Let's consider an example: allowing users to create secure sessions between two machines. With SSH, you simply install the SSH client on the first machine and the server on the second, start the server, and you're ready to go. Kerberos, however, requires the following administrative tasks:
Nov 12, 2020 Once the policy updates you will notice that the option Attempt Kerberos auth (SSH-2) is no longer configurable, and is greyed-out. I am going to preface the next part with a word of caution. We are going to disallow SSH public keys from being used, and this could have some adverse, unforeseen effects. Single Sign On with OpenSSH and Kerberos From a convenience perspective, I want to authenticate as infrequently as possible. However, security requirements suggest that I should be authenticated for all sorts of services. This means that Single Sign On and forwardable authentication credentials would be useful. About kerberos and ssh. If you have a valid kerberos ticket you can configure ssh to forward your credentials, allowing password-less connections to properly configured linux boxen. Kerberos Configuration. It is useful to create a kerberos config file. The Mac Self-Service can do that for you. Ssh kerberos mitkerberos. Improve this question. Follow edited Sep 26 '19 at 15:59. Asked Sep 23 '19 at 17:05. 81 3 3 bronze badges. Once creating that principal for SSH service, I used the ktadd -k command to add the keytab file (to be clear, SSH server and Kerberos server are on the same machine) located at /etc/krb5.keytab. The output of sudo klist -ke /etc/krb5.keytab is.
- Establish at least one Kerberos Key Distribution Center (KDC) host. The KDCs are central to the Kerberos system and must be heavily secured; typically they run nothing but the KDC, don't allow remote login access, and are kept in a physically secure location.[139] Kerberos can't operate without a KDC, so it is wise to establish backup or 'slave' KDCs also, which then must be synchronized periodically with the master. A KDC host might also run a remote administration server, a credentials-conversion server for Kerberos-4 compatibility in a Kerberos-5 installation, and other server programs depending on your needs.
[139]Although, if remote login access to a KDC is desired, SSH is a good way to do it!
If you have a valid kerberos ticket you can configure ssh to forward your credentials, allowing password-less connections to properly configured linux boxen.
Kerberos Configuration
It is useful to create a kerberos config file. The Mac Self-Service can do that for you. Once the config file is created you can run kinit yourCernAccountNameto create a kerberos token that you can use for your browser, for ssh, the Self-Service login and many other services.
ssh Configuration
You need to instruct ssh to use (or 'forward') your kerberos token to login to lxplus or other services. This can be done on the command line, or more conveniently via the ssh configuration.
The necessary configuration can be applied in two places on your Mac:
- In
/etc/ssh/ssh_config(notsshd_config!)(was/etc/ssh_configprior to OS 10.12). In that case it is applied to all accounts on the Mac. Editing this file requires sudo privileges, but we will see further down why we want to edit this in any case... - In
~/.ssh/config. In that case it is applied to the current Mac account only.
You should only forward your credentials to hosts that are trustworthy. If you forward your credentials to a roque host you run the risk that somebody abuses your credentials. So it is important to have the settings in question inside a 'Host' block for trusted hosts only! Do not put these settings in a 'Host *' block! In the following snippet the settings apply to the hosts 'lxplus.cern.ch', 'svn.cern.ch', 'mylinuxbox.cern.ch' and all hosts matching 'pcmydepmygroup*.cern.ch'.
#
Host lxplus.cern.ch aiadm.cern.ch mylinuxbox.cern.ch pcmydepmygroup*.cern.ch
GSSAPIAuthentication yes
GSSAPIDelegateCredentials yes
#...
About GSSAPITrustDNS
Up to OS 10.11.6 the built-in ssh and scp binaries supported the option GSSAPITrustDNS, which at that time was very useful for connecting to lxplus. This option is not supported any longer, but due to an improved configuration of lxplus it is also not needed any more. If you used it in the past you will have to remove it from your ssh configuration files.
About LANG LC_*
When connecting to lxplus or other linux boxen with OS prior to CC8, we might be greeted with messages like
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = 'UTF-8',
LANG = 'en_US.UTF-8'
are supported and installed on your system.
perl: warning: Falling back to the standard locale ('C').
We can avoid these by deleting or commenting out the line
SendEnv LANG LC_*
Gssapicleanupcredentials
from /etc/ssh/ssh_config. Unfortunately there is no way to achieve the same result by any parameter in ~/.ssh/config - and Apple overwrites /etc/ssh/ssh_config with almost every OS or security update :(
In case you have all required settings in ~/.ssh/config and do not need any of the settings from /etc/ssh/ssh_config you can use the ssh or scp option '-F ~/.ssh/config' to avoid reading /etc/ssh/ssh_config, and thus avoid being bother by Apple re-activating the SendEnv LANG LC_* with every update to ssh.
Kerberos Authentication Error
Configuring Firefox to use kerberos for SSO
To enable Firefox to use your kerberos token apply the following steps:
- type
about:configin the address bar - type
negotiatein the Search field - click on the edit button for the
network.negotiate-auth.trusted-urisfield - enter
cern.chin the text field
About git
The git version provided by Apple has a configuration that has problems handling git via kerberos. On cloning a repository you might get messages like
remote: HTTP Basic: Access denied
fatal: Authentication failed for 'https://:@gitlab.cern.ch:8443/macsupport/packaging-tools.git/'
To avoid this run git config --global http.emptyAuth true``
About third party software
Some popular package managers like brew, macports etc provide own versions on kinit, ssh,... Unfortunately these use different places to store the kerberos token and as a result are incompatible with the executables provided by macOS. We recommend not using any third party kerberos or ssh binaries.