ssh doesn't initialize environment

[GoogleCodeExporter]

What steps will reproduce the problem?

     gcloud compute ssh <hostname>
     ls -lu .bashrc .profile

What is the expected output? What do you see instead?

     The user's environment should be initialized from the .profile or .bashrc files.  These files are not sourced.

What is the output of 'gcloud info'?

     Google Cloud SDK [0.9.86]

Please provide any additional information below.

Original issue reported on code.google.com by van...@motivity.ca on 17 Nov 2015 at 6:48

[GoogleCodeExporter]

Thanks for reporting!

This is an artifact of how SSH works, and actually the intended behavior. See 
http://superuser.com/questions/564926/profile-is-not-loaded-when-using-ssh-ubunt
u for more details.

Original comment by z...@google.com on 17 Nov 2015 at 3:03

• Changed state: WorkingAsIntended

[GoogleCodeExporter]

If `gcloud compute ssh` is intended to be a workalike to ssh it should
execute a login shell (i.e. `bash -l`) when only a hostname is
provided.  That is how SSH works!

Original comment by van...@motivity.ca on 18 Nov 2015 at 4:48

[GoogleCodeExporter]

Apologies for my somewhat misleading response earlier; I didn't look into this 
deep enough. I can't reproduce the behavior you're talking about:

       $ gcloud compute ssh --zone <zone> <hostname>
       Warning: Permanently added '<IP>' (ECDSA) to the list of known hosts.
       Linux <hostname> 3.16.0-0.bpo.4-amd64 #1 SMP Debian 3.16.7-ckt11-1~bpo70+1 (2015-06-08) x86_64

       <user>@<hostname>:~$ echo $0
       -bash

"-bash" indicates that a login shell is used ("A login shell is one whose first 
character of argument zero is a -, or one started with the --login option.", 
from `man bash`).

The files you referred to are *not* invoked in a login shell. See again `man 
bash` (the "INVOCATION" section):

       When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands  from  the  file  /etc/profile,  if  that  file
       exists.   After  reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
       The --noprofile option may be used when the shell is started to inhibit this behavior.

       When a login shell exits, bash reads and executes commands from the file ~/.bash_logout, if it exists.

       When an interactive shell that is not a login shell is started, bash reads and executes commands from /etc/bash.bashrc and ~/.bashrc, if these files exist.  This may be inhibited by using the
       --norc option.  The --rcfile file option will force bash to read and execute commands from file instead of /etc/bash.bashrc and ~/.bashrc.

So `.bashrc` is *not* read in a non-login shell; `.profile` is only read if 
`.bash_profile` and `.bash_login` are both not found (can you check for this on 
your system?). Many operating systems will sour
ce `.bashrc` in the default `.bash_profile`; perhaps you're expecting this 
behavior?

This is all from the GNU bash 4.2 implementation on Debian 3.16.

It's unlikely that there are any significant behavioral differences between 
`gcloud compute ssh` and `ssh`, as the former invokes the latter under the 
hood. You can see this by running `gcloud compute ssh --dry-run`, which will 
print out the `ssh` command used (you should be able to run this). If you would 
like to use `ssh` directly more easily, you can run `gcloud compute 
config-ssh`, which will populate your `~/.ssh/config` with "Host" entries for 
each of your compute instances.

It is true that `gcloud compute ssh <hostname>` will run `ssh 
<user>@<hostname>` under the hood. Is there any point at which the behavior for 
`ssh <hostname>` and `ssh <user>@<hostname>` differ (except which user it logs 
in as, of course)? Can you point me to documentation about that?

Original comment by z...@google.com on 18 Nov 2015 at 1:44

[GoogleCodeExporter]

I created a new instance using the default OS and found it working as
expected (.profile is sourced).
I now blame my environment.  Sorry for the noise, everything is
functioning as expected.

Original comment by van...@motivity.ca on 18 Nov 2015 at 4:28