- Error message: kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED
- Problem: Your Kerberos account has expired.
- Solution: Please see the User Accounts web page for more information on renewing your Kerberos account.
- Error message: kinit(v5): Cannot find KDC for requested realm while getting initial credentials
- Problem: /etc/krb5.conf file does not contain .FNAL.GOV information.
- Solutions:
- Replace /etc/krb5.conf with your OS-specific Fermilab-supplied version of krb5.conf.
- Modify /etc/krb5.conf adding Fermilab-specific stanzas as instructed in the User Accounts web page.
- If user does not have permission to modify /etc/krb5.conf, copy Fermilab-supplied version into home area, and execute export KRB5_CONFIG=$HOME/krb5.conf to tell all Kerberos commands to use the user's copy of krb5.conf.
Related problem:
On Macintosh computers, Kerberos is installed on all recent versions. However, there are two locations and names for krb5.conf,
- /etc/krb5.conf
- and
- /Library/Preferences/edu.mit.Kerberos
(Note: the file in /Library is named edu.mit.Kerberos, not krb5.conf.) Either will work, but you should only have one.
- Error message: kinit: Unable to acquire credentials for 'user@FNAL.GOV': Cannot contact any KDC for realm 'FNAL.GOV'
- Problem: You are behind a firewall or are using an internet connection which has a "NAT" (Network Address Translation), such as on a home wireless router.
- Solutions:
- Step 1: Check your connectivity, as shown below, to one of the Fermilab Kerberos authentication servers (such as krb-fnal-1.fnal.gov) to make sure you can reach the server at the other end. If successful move to step 2. If fail, send us email at lqcd-admin@fnal.gov.
- [@mylaptop ~]$ telnet krb-fnal-1.fnal.gov 88
- Trying 131.225.110.105...
- Connected to krb-fnal-1.fnal.gov.
- Escape character is '^]'.
- ^]
-
- telnet> quit
- Connection closed.
- OR, in case of some mac OS versions that are missing the telnet utility, use the nc utility as follows:
- [@mylaptop ~]$ nc -vz krb-fnal-1.fnal.gov 88
- Connection to krb-fnal-1.fnal.gov port 88 [tcp/kerberos] succeeded
- Step 2: Request an address-less Kerberos ticket as follows:
- kinit -a username@FNAL.GOV
- If you do
- klist -a
- you should see as the last line
- Addresses: (none)
-
- Error message: kinit: Preauthentication failed while getting initial credentials
- Problem: kinit fails with preauthentication error.
- Solutions:
- Usually the problem is simply that you have typed in your kerberos password incorrectly. Please try again.
- If you have lost your kerberos password, call the Fermilab Service Desk at (630) 840 2345, during business hours to have the password reset.
- Occasionally this is not a password problem, but a problem with your system's clock. Make sure that the date command returns a time correct to within 5 minutes.
- Error message: kinit: krb5_get_init_creds: Too large time skew
- Problem: kinit fails with time skew message.
- Solution:
Your system clock must be within 5 minutes of the correct value.
- Error message: kinit: KDC has no support for encryption type while getting initial credentials
- Problem: kinit fails with complaint about encryption type.
- Solution:
This problem appears on recent Ubuntu and related Linux distributions. To fix, edit /etc/krb5.conf file, and in the [libdefaults] section add
allow_weak_crypto = true
- Error message: kinit: Client not found in Kerberos database while getting initial credentials
- Problem: kinit fails with database complaint.
- Solutions:
- Your kerberos principal may differ from your username on your local system. Use kinit username@FNAL.GOV where username is your Fermilab kerberos principle. kinit without options will default to using your local username.
- Your Fermilab ID or Visitor ID has expired. Please see the User Accounts web page for more information on renewing your Fermilab ID.
- Error message: kinit: Client's entry in database has expired
- Problem: kinit fails because of an expired password
- Solutions:
- You must change your kerberos password once a year with the kpasswd command. You can try to change your password, even if it is expired, by using kpasswd on your local machine. More detailed instructions are available here.
- You can also call the Fermilab Service Desk at (630) 840 2345, during business hours to have the password reset.
- Error message: kinit: Password incorrect
- Problem: If you are sure your Kerberos password is correct but you are on a MAC OS 10.10 (Yosemite) kinit will fail because the Kerberos pass phrase is DES encoded, which Yosemite no longer accepts.
- Solutions:
You will need to reset your Kerberos password as follows:
- You have access to a non-Yosemite machine with Kerberos client software installed, do kinit to obtain a Kerberos ticket and then SSH to one of our head nodes, for example lq.fnal.gov. Once there do a kpasswd to change your Kerberos password. Alternatively, you may call the Fermilab Service Desk at (630) 840 2345, during business hours and request that they reset your kerberos password.
- Update the krb5.conf file on your Yosemite machine with the latest version from Fermilab-supplied version posted here.
- On your Yosemite machine, go ahead and attempt kinit and ssh, which should now work.
|
- Error message: ssh_dispatch_run_fatal: Connection to 131.225.202.32: unexpected internal error
- Problem: You may have just upgraded to the new 'El Capitan' Mac OS X version or changed the SSH options on your client.
- Solution: Try to "ssh -o GSSAPIKeyExchange=no lq.fnal.gov" to one of our servers. If it works then add "GSSAPIKeyExchange no" to your SSH client config file (e.g. /etc/ssh/ssh_config).
- Error message: permission denied
- SSH login failures will be indicated by a permission denied message. If none of the solutions below fixes your problem please email the output of the command "ssh -vvv lq.fnal.gov" to lqcd-admin@fnal.gov for further assistance.
-
- Problem: Kerberos client and SSH using different credential cache file locations.
- Solution: We have mostly encountered this on MAC 10.9.x versions where Kerberos clients are installed from two different sources. In such a situation Kerberos client binaries end up in /opt/local/bin and in /usr/bin. Use the Kerberos client kinit installed in /usr/bin to obtain a Kerberos ticket. Also make sure there is a subdirectory .ssh in your home directory. Make sure the subdirectory has a file named config with the following lines:
- Host *.fnal.gov
- GSSAPIAuthentication yes
- GSSAPIDelegateCredentials yes
- GSSAPITrustDNS yes
- Problem: Not having a kerberos ticket granting ticket (TGT), or having an expired TGT.
- Solution: Verify with the klist -f command that you have a ticket. If you don't have a ticket, or have an expired ticket, get a new ticket with kinit as follows:
- lqcdp4ee:~$ kinit -fr 7d username@FNAL.GOV
- lqcdp4ee:~$ klist -f
- Ticket cache: /tmp/krb5cc_1234
- Default principal: username@FNAL.GOV
-
- Valid starting ·· Expires·········· Service principal
- 08/17/12 09:31:16 08/18/12 11:31:16 krbtgt/FNAL.GOV@FNAL.GOV
- renew until 08/24/12 09:31:09, Flags: FRIA
Normal output, indicating that a forwardable, renewable, ticket exists. Check the expiration time - if the current time is past the expiration, login attempts will fail.
- lqcdp4ee:~$ klist -f
- klist: No credentials cache file found (ticket cache /tmp/krb5cc_5598)
If you see the above message you do not have a Kerberos ticket. Use kinit to get a ticket before attempting to login. Kerberos tickets expire after 24 hours. If you include the -r 7d switch on your kinit command line, you will receive a renewable ticket. Renewable tickets may be renewed by typing kinit -R before they expire at the end of any 24 hour period. Tickets are renewable for up to the period specified in the -r switch, to a maximum of 7 days.
Another useful switch to kinit is -f, which asks for a forwardable ticket. If you have a forwardable ticket, once you login to a Fermilab machine, say lq.fnal.gov, you can then login from lq to another machine without executing a new kinit. It is in general a bad idea to use kinit on any machine but your local system, as your password may be captured as it traverses the internet. The only time typing a kinit password is safe on a remote machine is when you are using an encrypted connection, like with ssh.
- Problem: Not having an account on the target machine, or having an account on the target machine under a different username.
- Solution: A permission denied error will occur if you do not have an account on the target machine, or if your username on the target machine differs from your username on your local machine. Try
-
- ssh username@lq.fnal.gov
- or
- ssh -l username lq.fnal.gov
where username is your Fermilab username (the same name that you used in your kinit command). If this fails, send e-mail to lqcd-admin@fnal.gov and ask that the administrators verify that you have a valid account on the Fermilab lattice QCD systems.
- Problem: Using an internet connection which has a "NAT" (Network Address Translation), such as on a home wireless router
- Solution: Nearly all home routers, wired or wireless, have a "NAT" function, which results in your local system having a different local network address than what is presented to remote machines. This allows you to have multiple local machines and only one external IP address. Your local addresses will generally be something like 192.168.X.Y, or 10.X.Y.Z, when a NAT is present.
With a NAT, your ssh logins may fail with Incorrect net address. To fix this, use "address-less" tickets. First, use kdestroy to delete your current ticket. Then, use kinit with -a, -A, or -n to request an address-less ticket. The switch required varies with kerberos versions, so use man kinit on your local system to determine which of these three switches to use.
For Mac OS users, please be aware that the default behaviour on Mac OS is to supply address-less tickets, so you should also be able to simply drop the -A or -a switch entirely.
- Problem: Using an SSH client which does not have Kerberos authentication enabled
- Solution: Some versions of ssh will not attempt to perform kerberos authentication. In this case, you will receive a permission denied error. To enable kerberos authentication, try the following -o switch:
ssh -o "GSSAPIAuthentication yes" username@lq.fnal.gov
The quotation marks are required. If this form of SSH succeeds, you can configure your local system to always attempt to use kerberos authentication by editing either $HOME/.ssh/config or /etc/ssh/ssh_config and adding these lines:
- Host *.fnal.gov
- GSSAPIAuthentication yes
- GSSAPIDelegateCredentials yes
The GSSAPIDelegateCredentials line is necessary if you want to use X-windows clients on the remote (Fermilab) system. Note that you may also need a -X or -Y switch on your ssh command to enable X forwarding.
|