SSH Usage Guide

Checklist of issues affecting ssh connections to Fermilab

General debugging

See the most common issues listed below.
  • To debug the connection process, do
    • ssh -v
    • and for really full details, ssh -vvv


  • Problems with kinit are usually due to the clock.
    • kerberos requires that clocks be correct to within 5 minutes.
    • Check that the UTC time from date -u is correct.
    • Clocks are usually correct to within a second.
  • Do you have a valid kerberos ticket ?
    • klist -f
  • Has your Fermilab ID card expired ?
    • If so, you will be unable to kinit.
  • If you cannot get a kerberos ticket, is your system's Linux /etc/krb5.conf up to date ?
  • Do you have an addressless ticket, if working behind a NAT, as is often the case outside Fermilab ?
    • Look for the A flag in the klist -f output.
    • To get an addressless ticket, depending on your kinit version, do one of
      • kinit -A
      • kinit -n
  • Are you using an ssh which supports kerberized ssh ?
  • Are you using /usr/kerberos/bin/kinit, not the JRE or java version ?
    • type which kinit
  • Your /etc/ssh/ssh_config should have something like :
    Host *
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials yes
    ForwardX11Trusted yes
    ForwardX11 yes
    • You can override this with
      • ssh -o "GSSAPIAuthentication yes" -o "GSSAPIDelegateCredentials yes" ...
  • Forwarding X requires an AFS token on systems with AFS login areas
    • This requires a forwarded Kerberos ticket
    • Test that the ticket is forwardable, look for Flags: F
      • klist -f
      • Getting a forwardable ticket may require kinit -f
    • Some clients may require forced forwarding with ssh -k
    • Test functionality with
      • ssh -k user@host  /usr/krb5/bin/klist 
      • ssh -k user@host  tokens


  • Do you have an account on the destination system ?
    • The account must not be expired.
    • The destination account name might not be the same as on your source system.
      • In this case, ssh remote-username@host
  • Check that /etc/hosts.allow permits a connection. It should contain something like
    • sshd: ALL
  • The authorization record for the user should not contain !! as a password
    • ( /etc/passwd or /etc/shadow or ypcat passwd )
    • * ( star ) or KERBEROS or x are acceptable password fillers
  • The /etc/hosts file must contain something like : localhost.localdomain localhost
    • This sometimes gets mangled or dropped during system installations or upgrades
  • If you have a .k5login file, remove any trailing blanks.
    • Trailing blanks cause lines to be ignored
  • Some service aliases map to several possible clients ( nova-offline, minos-int )
    • You may need to set
      GSSAPITrustDns        yes
      StrictHostKeyChecking  no
    • Test interactively with
      ssh -o GSSAPITrustDns=yes -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null ...