Could not chdir to home directory /nashome/b/bv: Permission denied

[brettviren]

❯ kinit bv@FNAL.GOV
Password for bv@FNAL.GOV:
❯ ssh bv@dunegpvm02.fnal.gov
...
Could not chdir to home directory /nashome/b/bv: Permission denied
------------------------------------------------------------------------------
                     ..::Powered by ECF-SSI::..                      

   Hostname: dunegpvm02.fnal.gov         OS Release: SLF 7.9 (Nitrogen)        
         IP: 131.225.67.247                  Subnet: 255.255.255.0             

     Kernel: 3.10.0-1160.25.1                  Arch: x86_64                    
        RAM: 9.60 GiB                          Swap: 2.00 GiB                  
      Cores: 4                              Virtual: rhev                      

 SSH Logins: 5                             Load Avg: 0.77 1.06 1.18            

       Help: https://ssiwiki.fnal.gov/wiki/Interactive_Server_Facility         
------------------------------------------------------------------------------
-bash: /nashome/b/bv/.bash_profile: Permission denied
-bash-4.2$ pwd
/

[brettviren]

The solution is to kinit bv@FNAL.GOV on the remote end after login. This will immediately give access to $HOME though of course for the immediate session, the normal shell setup is still not active.

This access grant seems to "stick" so a subsequent ssh to the same remote host will give access to $HOME. But, I had to repeat this for every gpvmXX (for dune and uboone).

Note, this doesn't seem to have anything to do with kinit -f. After the remote kinit, I am able to do a simple kinit locally and connect.

[hschellman]

This happens occasionally, when kinit -f in fact doesn't forward your kerberos fitter.

[calcuttj]

This issue is avoided if you kinit and then log in with the following set of flags

ssh -YKX

I think -K is the only one that fixes this issue, though -Y and -X are useful for using GUI/ROOT displays (with a VNC of course)

[calcuttj]

You can also add this to your .ssh/config on your local machine to achieve the same functionality, as well as allow you to simply type ssh duneXY to log in to your desired version

 1 Host dune01
  2         HostName dunegpvm01.fnal.gov
  3 
  4 Host dune02
  5         HostName dunegpvm02.fnal.gov
  6 
  7 Host dune03
  8         HostName dunegpvm03.fnal.gov
  9 
.... (skipping extra lines)
 34 Host dune11
 35         HostName dunegpvm11.fnal.gov
 36 
 37 Host dune12
 38         HostName dunegpvm12.fnal.gov
 39 
 40 Host dune0* dune1*
 41         User calcuttj
 42         ForwardX11 yes
 43         ForwardX11Trusted yes
 44         GSSAPIDelegateCredentials yes
 45 

[tomjunk]

It is not advisable to run kinit on a remote machine on a regular basis, although I've seen advice that if you have to do it once in a while (say to rescue a session with an expired ticket and you need to save some work), then not to get too worried. Even though the connection may be encrypted end to end, it is still possible for a malicious actor to steal a password. Many years ago, someone installed a keylogger on one of the CDF interactive servers. It collected several users' passwords before being discovered. We just changed our passwords after being notified about it.

[illingwo]

If you find your Kerberos tickets are not being forwarded correctly, make sure that you are using the OS kinit executable (/usr/bin/kinit). In particular conda is known to provide its own copy that does not work properly.