You are not logged in.
Hi All,
Posting here because I don't know what is good practice in this case with Arch.
When I try to copy files to my Arch server with scp or rsync it fails because it is using a non-interactive ssh session and the PATH environment is not being set.
This can be modified by editing /etc/environment and setting as follows
BASH_ENV=/etc/profile
This unfortunately sets my ~/.pam_environment first and then the /etc/profile after producing a mangled path.
Some background
I have had to modify my ~/.pam_environment as follows...
PATH DEFAULT=${PATH}:@{HOME}/.local/bin:@{HOME}/.local/share/gem/ruby/3.0.0/bin
This is because I am using Emacs client, which does not source any of the .bash_profile or .bashrc and needs this path extension.
I've no doubt that this is something that many server admins have come across as they send files back and forth, so I'm wondering what the preferred, secure or/and recommended method of getting a path on a non-interactive ssh session is?
I could set the path to a constant value in via /etc/environment and ignore the /etc/profile but is this advisable? How are others configuring their servers for rsync or scp and getting this to work for non-interactive sessions? Is it my SSHD config that needs adjustment? I've not changed much yet on this server so it's pretty much the default settings.
Any assistance would be very much appreciated. Perhaps a note on the Openssh arch wiki could be useful to assist others? I see a few threads on this issue around the web, so others are struggling, but no answers that works with ~/.pam_environment additions to the PATH. Maybe these should be moved to /etc/environment and out of the users home folders?
Offline
Offline
Thanks for the suggestions. In reverse order answers below.
PermitUserEnvironment is discouraged apparently for security but not an issue if you have trusted users. For that reason others have not recommended this.
AcceptEnv requires the client to have knowledge of the system environment in advance, in order to know what to set the path to. I don't think it's usual for users to know what to set the path to when copying files.
SetEnv could work but it would require repetition of the specification of the PATH in multiple places on the system as in normal operation we'd essentially be overriding the path for ssh sessions set in /etc/profile for interactive sessions. One of the reasons I didn't set a static path in /etc/environment is that repetition of PATH definition. Sticking to the Don't Repeat Yourself principal from software development, suggests that specifying the PATH in multiple repeated places will make changes to the PATH and debugging issues with changes to the PATH later down the line harder, especially for other sysadmins. So repeating the definition of PATH doesn't feel like a best practice solution. Interestingly I didn't see SetEnv advised anywhere else. Their preference was for BASH_ENV=~/.bashrc in /etc/environment, which didn't work for me as that wasn't where the path was set in Arch, so I updated to BASH_ENV=/etc/profile as outlined in my question above.
Offline