I need to run this command from Ubuntu machine: ssh user#hostip "which mvn" to show excutable path of Maven , but it show nothing
root#~: ssh user#hostip "which mvn"
root#~:
I check command which mvn on remote host it show me :
root#~: which mvn
/usr/share/mvn
root#~:
I try to sourcing .bashrc when excute ssh command but no luck:
root#~: ssh user#hostip ". ~/.bashrc;which mvn"
root#~:
In ./bashrc also have nothing about maven PATH configure
So , what i have to do ?
root#~: ssh user#hostip "which mvn"
When you run ssh and specify a command to invoke on the remote system, ssh by default doesn't allocate a PTY (pseudo-TTY) for the remote session. Shells like bash will detect that they're running without a TTY, and this will alter how the shell process initializes itself.
In your case, whatever command adds "/usr/share" to your remote PATH is probably not running for non-interactive sessions (sessions without a TTY).
You can probably solve this by telling ssh to request a TTY for the remote session:
ssh -tt user#hostip "which mvn"
The -t option tells ssh to request a TTY for the remote session. This would cause your remote shell instance to initialize itself for an interactive session. Refer to the ssh manual for details on the -t option.
If this doesn't solve the problem, you will need to find the point in your shell configuration files on the remote server (.bash_profile, .bashrc, etc.) where /usr/share is being added to your PATH, and make sure that step is performed for non-interactive sessions.
Related
When executing an SSH session that simply launches a command instead of actually connecting you, it appears as though my PATH environmental variable differs from when I connect to the SSH session normally, and it's missing the location of my binaries for bash commands. Why would this be, and how can I avoid it?
Normal connection of : ssh root#host
Yields a PATH env of
PATH='/sbin;/usr/sbin;/proc/boot'
An ssh to execute command but not connect to the terminal directy (ssh root#host ls) yields "ls: command not found". Upon further inspection, the PATH environmental variable is missing /proc/boot, and thus missing the location of the ls binary file.
The PATH env of this 'non terminal' session yields:
PATH='/usr/sbin;/sbin'
but NOT /proc/boot, so it can't call standard actions like ls,mkdir, etc.
Why is this? How can I get my proper PATH when simply executing a command over SSH, but not connecting directly to a displayed terminal?
Run the .profile of the remote server before running commands
ssh user#host "~/.bash_profile; $command"
#!/bin/bash
dets () {
sleep 1;
echo $1
sleep 1
}
dets "$1" | ssh -T username#ipaddress
Try using the above script passing the command you want to execute to the script i.e. ./sshscr "ls" This will disable pseudo-tty allocation (-T) and then execute the commands through a function det with the commands passed.
This is actually a feature. When you use a terminal ssh session, you get an interactive login session. So the sshd daemon starts your login shell (the one that is declared in /etc/password) as a login shell. The profile files are read and initialize various environment parameters and you can the start entering commands - for old dinosaurs it is the rlogin mode, for younger guys it is just a login mode
When you pass a remote command directly on the ssh line, none of the above occurs. The sshd daemon just sets up a default environment and launches the command - it is the rsh mode for dinosaurs or command mode for younger ones.
How to fix:
The best way is to not rely on the PATH when you pass commands directly in the ssh line:
ssh root#host /bin/ls
Alternatively, you can pass commands to an interactive shell (assuming bash on linux):
echo 'ls' | ssh root#host "bash -i"
But beware it is just an interactive shell, not a login shell: the ~/.bashrc will be read, but not ~/.profile nor ~/.bash_profile
I have to maintain a bash script.
There several commands are executed via ssh on a remote machine. The following command is used to do so:
ssh $1#$2 ${SSH_OPTS:-} "${CONFIG}; REC=y . \$HOME/.profile; $3 2>&1"
I have some troubles to understand what REC=y . \$HOME/.profile; does. Something with sourcing the .profile on the remote machine but what is REC=yfor?
I am trying to call an installation of node.js on a remote server running Ubuntu via SSH. Node has been installed via nvm.
SSHing in and calling node works just fine:
user#localmachine:~$ ssh user#remoteserver
(Server welcome text)
user#remoteserver:~$ which node
/home/user/.nvm/v0.10.00/bin/node
However if I combine it into one line:
user#localmachine:~$ ssh user#remoteserver "which ls"
/bin/ls
user#localmachine:~$ ssh user#remoteserver "which node"
No sign of node, so I tried sourcing .bashrc and waiting 10 seconds:
user#localmachine:~$ ssh user#remoteserver "source ~/.bashrc; sleep 10; which node"
Only node seems affected by this. One thing I did notice was that if I ssh in and then check which shell I'm in it says -bash whilst if I ssh direct it gives me /bin/bash. I tried running the commands inside a bash login shell:
user#localmachine:~$ ssh user#remoteserver 'bash --login -c "which node"'
Still nothing.
Basically my question is: Why isn't bash finding my node.js installation when I call it non-interactively from SSH?
Another approach is to run bash in interactive mode with the -i flag:
user#localmachine:~$ ssh user#remoteserver "bash -i -c 'which node'"
/home/user/.nvm/v0.10.00/bin/node
$ ssh user#remoteserver "which node"
When you run ssh and specify a command to be run on the remote system, ssh by default doesn't allocate a PTY (pseudo-TTY) for the session. Not having a TTY causes your remote shell process (ie, bash) to initialize as a non-interactive session instead of an interactive session. This can alter how it interprets your initialization files--.bashrc, .bash_profile, and so on.
The actual problem is probably that the line which adds /home/user/.nvm/v0.10.00/bin to your command PATH isn't executing for non-interactive sessions. There are two ways to resolve this:
Find the command in your initialization file(s) which adds /home/user/.nvm/v0.10.00/bin to your command path, figure out why it's not running for non-interactive sessions, and correct it.
Run ssh with the -t option. This tells it to allocate a PTY for the remote session. Or add the line RequestTTY yes to your .ssh/config file on the local host.
I have a Linux box (Ubuntu Server 13.04) which needs to run a job on a Windows 7 box (with cygwin installed) under a specific user's account. I have set up a password-less login to access the Windows machine through openSSH.
The problem I face is the following: when I manually ssh into the Win7 machine and launch the job everything is fine. However, when I launch the job using ssh winuser#winmachine command, I end up connecting to the Windows machine under the privileged sshd user 'cyg_server':
$ whoami
linuxuser
$ ssh winuser#Win7
$ whoami
winuser
$ exit
$ ssh winuser#Win7 "whoami; exit"
cyg_server
>> This should be 'winuser' too.
Why could this be happening? I have tried running ssh-host-config again to no avail. I don't see what parameters might influence this in sshd_config either.
Any help is greatly appreciated!
I had similar issues when I was connecting to a Cygwin machine using SSH. I used to have no problems logging on until one day I noticed that my path wasn't set correctly. I spent ages recreating the configuration files with ssh-host-config only to find my answer in the man page for ssh:
If command is specified, it is executed on the remote host instead of
a login shell.
The problem was the alias I had used to connect to the machine had been changed to connect to a screen session automatically (screen -DR). That meant that if there wasn't already a screen session to attach to, screen was not being run as a child process of a user login shell and not inheriting any of the relevant user environment.
When you provide a command as an argument to ssh, the resulting command is run as a process started by cyg_server. Ensuring the SSH command is being run as part of a login shell should do what you want:
ssh winuser#Win7 "bash -l -c 'whoami; exit'"
Explanation (from the bash man page):
-c string If the -c option is present, then commands are read from string.
-l Make bash act as if it had been invoked as a login shell.
my development server has a running Gnome-Desktop. I am connected to it by a ssh session. The Gnome-Session and the ssh session are running with the same user.
How to I start a Gnome-application (for example gedit) from the ssh remote session so that it appears on the remote servers Gnome-Desktop?
Thanks a lot,
Hacksteak25
This would probably work:
Tcsh:
setenv DISPLAY :0
gedit
Bash:
export DISPLAY=:0
gedit
If you are not the user that is logged into the Gnome session, then you would need to do xhost + to disable the authentication.
If the above doesn't work, then instead of :0, try simply copying the DISPLAY environment variable to the ssh terminal.
To support DBUS messaging, use:
ssh -Y remoteuser#remotehost dbus-launch -f gedit
The "-f" option starts the remote GUI application on the local desktop and returns, leaving the local terminal available for the next command.