NVM installation per user is not working with automated ssh logins - bash

Normally when I login to my server via putty, I am able to use nvm, grunt, gulp commands but if I connect with php's ssh2 extension or with sshpass through a bash script those commands are not working unless if I execute this commands first:
~/.nvm/nvm.sh
source ~/.profile
nvm current
And this is my ~/.profile file:
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
What seems to be issue ? Why I need to execute this commands every time with automation tools such as ssh2 or sshpass ?
My OS is ubuntu 16.04

This has nothing to do with sshpass. You can verify this by running the ssh session without sshpass, and you will see that even if you manually enter the password, it will still not work.
When you run ssh with a command after it, it starts a remote shell that is not connected to a TTY, and that shell is not considered a login shell. For non-login shells, .profile simply isn't run.
The simple solution this problem is to move the environment setup from .profile to .bashrc. .bashrc is run even for non-interactive shells, and so should provide the environment setup you need.
As a side note, why are you using sshpass at all? Why not use the more secure public key authentication?
To clarify, the fact that the shell is not connected to a TTY is unrelated to your problem. At least for openssh, you can tell it to open a TTY even if a command to run is provided by specifying -t on the command line. .profile will still not be run.

Related

How to launch WSL as if I've logged in?

I have a WSL Ubuntu distro that I've set up so that when I login 4 services start working, including a web API that I can test via Swagger to verify it is up and working.
I'm at the point where what I want to do now is start WSL via a script - that is, launch my distro, have all of the services start, and do it from Python. The problem is I cannot even figure out the correct syntax to get WSL to start from PowerShell in a manner where my services start.
Side note: "services" != systemctl (or similar) calls, but just executing bash CLI commands from either my .bashrc or .profile at login.
I've put the commands to execute in .profile & .bashrc. I've configured it both for root execution and non-root user execution. I've taken the commands out of those 2 files and put it into a script in the Windows file system that I pass in on the start of wsl. And I've put that shell script in the WSL file system as well. Nothing seems to work, and sometimes the distro starts and then stops after about 30 seconds.
Some of the PS CLI commands I've tried:
Start-Job -ScriptBlock{ wsl -d distro -u root }
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c /root/bin/start.sh'
Start-Job -ScriptBlock{ wsl -d distro -u root 'bash -i -l -c .\start.sh'
wsl -d distro -u root -- bash -i -l -c /root/bin/start.sh
wsl -d distro -u root -- bash -i -l -c .\start.sh
wsl -d distro -u root -- /root/bin/start.sh
Permutations of the above that I've tried: replace root with my default login, and turning all of the Start-Job bash options into a comma-separated list of single-quoted strings (Ex: 'bash', '-i', '-l', ... ). Nothing I launch from the CLI will allow me access to the web API that is supposed to be hosted on my distro.
Any advice on what to try next?
Not necessarily an answer here as much as troubleshooting tips which will hopefully lead to an answer:
First, most of the forms that you are using seem to be correct. The only ones that absolutely shouldn't work are those that attempt to run the script from the Windows filesystem.
Make sure that you have a shebang line starting your script. I'm assuming you do, but other readers may come across this as well. For the moment, try this form:
#!/usr/bin/env -S bash -li
That's going to have the same effect as the bash -li you tried -- It will source both both interactive startup files such as ~/.bashrc as well as login profiles such as ~/.bash_profile (and /etc/profile.d/*, etc.).
Note that preferably, you won't need the -li. Best practice would be to move anything necessary for the services over from the startup scripts to your start.sh script, and avoid parsing the profile and rc. I need to go update some of my answers, since I just realized I've been guilty of giving some potentially bad advice ...
Specifically, though, I'm wondering if your interactive Bash config has something truly, well, "interactive" in it that might be preventing the automatic running of the script itself. Again, best practice would be for ~/.bashrc to only hold configuration that is needed for interactive shell sessions.
Make sure the script is set as executable (chmod +x start.sh). Again, I'm assuming this is the case for you.
With a shebang line and an executable script, use something like:
wsl -d distro -u root -e /root/bin/start.sh
The -e tells WSL to launch the script directly. Since it has a shebang line, it will be parsed by Bash. Most of the other forms you use above actually run Bash twice - Once when launching WSL and another when it finds the shebang line in the script.
Try some basic troubleshooting for your script like:
Add set -x to the top (right under the shebang line) to turn on script debugging.
Add a ps -efH at the end to show the processes that are running when the script completes
If needed, resort to quick-and-dirty echo statements to show where things have progressed in the script.
I'm hopeful that the above will at least show you the problem, but if not, add the debugging info that you gain from this to your question, and we can troubleshoot further.

Prevent .bash_profile from executing when connecting via SSH

I have several servers running Ubuntu 18.04.3 LTS. Although it's considered bad practice to auto login, I understand the risks.
I've done the following to auto-login the user:
sudo mkdir /etc/systemd/system/getty#tty1.service.d
sudo nano /etc/systemd/system/getty#tty1.service.d/override.conf
Then I add the following to the file:
[Service]
ExecStart=
ExecStart=-/sbin/agetty --noissue --autologin my_user %I $TERM
Type=idle
Then, I edit the following file for the user to be able to automatically start a program:
sudo nano /home/my_user/.bash_profile
# Add this to the file:
cd /home/my_user/my_program
sudo ./program
This works great on the console when the server starts, however, when I SSH into the server, the same program is started and I don't want that.
The simplest solution is to SSH with a different user but is there a way to prevent the program from running when I SSH in using the same user?
The easy approach is to check the environment for variables ssh sets; there are several.
# only run my_program on login if not connecting via ssh
if [ -z "$SSH_CLIENT" ]; then
cd /home/my_user/my_program && sudo ./program
fi

A Bash script which runs commands in two terminal / ssh sessions

I'm trying to automate setting up and configuring a vagrant process with a bash script.
The thing is, I need to to ssh into my vagrant machine twice, and I want both terminals to be visible on my screen whilst doing this.
The process is like so...
In terminal 1:
vagrant up
vagrant ssh myhost
wait
cd /my/directory/
... do some commands...
Then I want this terminal to persist / stay open, and a new tab to open where another vagrant session starts
wait
cd /my/other/directory
.... do some commands...
I've got the script working for the first vagrant/terminal session and stored in my /bin/ directory, but how do I add the second?
How it looks exactly depends on the terminal emulator, but the basic pattern could be as follows:
First script (script1.sh)
vagrant up
vagrant ssh myhost
wait
cd /my/directory/
xterm -e script2.sh &
... do some commands...
Second script (script2.sh)
wait
cd /my/other/directory
.... do some commands...
The trick is to open another terminal window from the first script (for xterm its xterm -e).
In case you are interested in a way that works indepedently of the terminal emulator, consider using tmux (terminal multiplexer).
Other general hint: It is generally not recommended to store locally-created scripts under /bin. A more common place would be /usr/local/bin or $HOME/bin (although $HOME/bin might need to be configured separately).

sudo: command not found while using plink

Hi i have created a batch file (run.bat) that after execution connects me to UNIX server with help of plink. But issue starts from this point i have to execute a script after connection to my server the script contains a command sudo -l. After the execution i get the error as mentioned in subject can anyone help me on this issue ??
Batch File-:
"C:\Program Files\PuTTY" plink -ssh -pw Tos#12Ts w44dvftyw#caa1607UX009.wvd.abcd.net /opt/sieb/w44dvftyw/run.sh
Script file(run.sh) -:
#!/bin/bash
sudo -l
It says
sudo: command not found
But when i run my script normally on UNIX server it runs with no issues. What am i missing here to make it work this way please help.
Scripts such as ~/.profile or ~/.bash_profile responsible for setting up the current user's PATH are run only on login shells.
Running sh -c 'somescript' (as performed by ssh host 'somescript') is neither a login shell, nor an interactive shell; thus, it does not gain the benefit of such scripts.
This means that additions to the PATH (in your case, /usr/local/bin) may not be present with commands run in this way.
Among your options:
Pass the PATH you want as part of the command to remotely run. This might look like:
plink -ssh user#host "PATH=/bin:/usr/bin:/usr/local/bin /opt/sieb/w44dvftyw/run.sh"
Embed a working value in the script you're running:
#!/bin/bash
PATH=/bin:/usr/bin:/usr/local/bin
# ...put the rest of your script here.

bash-completion (from Homebrew) not completing variables on OSX

I use bash completion all the time to save typing. However there is an oddity I am unable to figure out how to fix on OSX.
If I install bash-completion using Homebrew (brew install bash-completion) and set it up in .bashrc, the tab key will no longer complete environment variables. Without this installed, environment variable completion works as expected.
For example, I have shortcuts for all my SSH accounts for clients... instead of typing ssh myuser#somecrazydomain.com I can just type ssh $SSHCRAZY which is much easier to remember.
Expected behavior: In the built-in bash in OSX I can type ssh $SSHC and hit tab and it completes to the full command as expected. This is what I want.
Observed behavior: In bash using the homebrew bash-completion additions, hitting tab has no effect for environment variables.
Note: All other extensions added by the bash-completion project are desired (git command completion, etc). I don't want to uninstall it, I just want it to also work with environment variables.
Thanks in advance for any help!
You might consider using an SSH config file (~/.ssh/config) to set up your SSH shortcuts instead of using environment variables. You could put into that file:
Host crazy
HostName somecrazydomain.com
User myuser
Then you can just type ssh crazy.
I guess bash-completion must have defined completion rule for ssh. So try add the -o bashdefault option in your .bashrc. For example, if complete -p ssh output like this:
# complete -p ssh
complete -F _func ssh
#
then you can add this to your .bashrc (or .bash_profile):
complete -F _func -o bashdefault ssh
or
eval "$(complete -p ssh | sed 's/ssh$/-o bashdefault ssh/')"

Resources