I am trying to run a remote script through a script in my host environment from the ExecuteProcess processor in NiFi. Basically, the shell script in the host server has the ssh string calling the remote server and then calling the script in that remote server. I used sshpass package where I saved the password in an environment variable(SSHPASS) and passed that in the ssh string.For more info on sshpass, https://linux.die.net/man/1/sshpass . The host script content is as follows:
sshpass -e ssh user#host sh /path-to-script
When I passed the host script path to the command property of the ExecuteProcess processor, the result of the processor showed that it didn't login to the remote server. So, after some debugging, I created a user defined property in the processor that specified the environment variable SSHPASS and its value which is the password of the remote server and then it worked.
I exported the password as an environment variable so that I don't have to pass it as cleartext in the first place. Is there any workaround where I don't have to specify the environment variable value ? Any suggestions on any other method to connect to the remote server and call the script is welcome too.
Have you tried using the -f or -d options for sshpass? They allow you to read the password from a file or file descriptor respectively. This way you can use OS-level access controls to restrict access to the file rather than having the password in an environment variable which other users or processes may be able to access.
I can investigate further why the executed process apparently did not have access to the environment variable value if those options are not sufficient.
Related
I want to run local commands with remote files in ssh, such as:
ssh server
# on server
!<local command> and remote files for executing
# still on the server
some other commands
Both remote and local are Linux systems. I guess this should be feasible, which is equivalent to passing a remote file to a local command for execution without exiting the ssh session (for example, using a local compiler to compile a remote file and generate a compiled file to the remote path where the ssh session is located). But I'm not sure if this is possible with the current ssh.
I'm newbie to Linux and trying to set up a passphrase-less ssh. I'm following the instructions in this link: http://wiki.hands.com/howto/passphraseless-ssh/.
In the above link, it said:"One often sees people using passphrase-less ssh keys for things like cron jobs that do things like this:"
scp /etc/bind/named.conf* otherdns:/etc/bind/
ssh otherdns /usr/sbin/rndc reload
which is dangerous because the key that's being used here is being offered root write access, when it need not be.
I'm kind of confused by the above commands.
I understand the usage of scp. But for ssh, what does it mean "ssh otherdns /usr/sbin/rndc reload"?
"the key that's being used here is being offered root write access."
Can anyone also help explain this sentence more detail? Based on my understanding, the key is the public key generated by one server and copied
to otherdns. What does it mean "being offered root write access"?
it means to run a command on a remote server.
the syntax is
ssh <remote> <cmd>
so in your case
ssh otherdns /usr/sbin/rndc reload
is basically 4 parts:
ssh: run the ssh executable
otherdns: is the remote server; it's lacking a user information, so the default user (the same as currently logged in; or the one configured in ~/.ssh/config for this remote machine)
/usr/sbin/rndc is a programm on the remote server to be run
reload is an argument to the program to be run on the remote machine
so in plain words, your command means:
run the program /usr/sbin/rndc with the argument reload on the remote machine otherdns
I'm creating files on a Linux server that I'm logged into and I'm adding the ability for the user to download these files from the Linux server on to the connecting computer. I'm writing a scrip and using the scp command to download these files:
scp data.txt user#usraddress:/home/usr
However, I don't want to specify "user#usraddress:/home/usr" to be just my computer. I want whoever is logged onto the linux server to be able do download these files. Is there a way to get the address of the connecting computer?
How would I do this?
Forgive me if this seems elementary, I'm very new to scripting.
When you open a remote session in a GNU/Linux machine, the ssh server sets the environment variable SSH_CONNECTION with some connection information. You can use this variable and the $USER variable to fill that parameters:
scp data.txt $USER#${SSH_CONNECTION%% *}:/home/$USER
Note that as far as I know you couldn't assume the client home directory is at /home. As said by chepner, you could omit the destination directory to use the default location, the home directory.
scp data.txt $USER#${SSH_CONNECTION%% *}:
I have a daemon process running on a server that needs access to an environment variable that specifies file path information (e.g. MYPATH=/a/b/c). I know how to specify this in my .bashrc file to give me access while I'm on the interactive shell, but unclear how to make sure a value accessible to a daemon process that's running as root.
In short, my question is: How do I set an environment variable that can be accessible by a daemon process running as root?
Write a script - like
#!/bin/sh
export MY_VAR="some value"
exec /path/to/daemon
Put it in /etc/rc.X to use this script.
See the manual page for that (and read what does the numbers mean in /etc/rcX.d?)
I am attempting to execute a command on a remote linux server via an ssh command on a local server like this:
ssh myremoteserver 'type ttisql'
where ttisql is an executable on the path of my remote machine.
The result of running this is:
bash: line 0: type: ttisql: not found
When I simply connect first and do:
ssh myremoteserver
and then enter the command:
[myuser#myremoteserver~]$: type ttisql
I get back the path of the ttisql exe as I would expect.
The odd thing is that when I execute the first command in my beta environment it works as expected and returns the path of the exe. In the beta scenario, machine A is connecting to remote machine B but both machines are onsite and the ssh command connects to the remote machine quickly.
The problem is encountered in our production environment when machine A is local and machine B is offsite and the ssh command takes a second or two to connect.
The only difference I can see is the time it takes the production ssh to connect. The path on the remote system is correct since the command works if entered after the initial connection.
Can anyone help me understand why this simple command would work in one environment and not the other? Could the problem be related to the time it takes to connect via ssh?
Your PATH is setup differently when your shell is interactive (= when you are logged in on the server), and when not interactive (running commands with ssh).
Look into the rc files used by your shell, for example .bashrc, .bash_profile, .profile (depends on your system). If you set PATH at the right place, then ttisql can work when you run it via ssh.
Another solution is to use the absolute path of ttisql, then it will not depend on your PATH setup.
The environment can be different in a non-interactive session (ssh command) from an interactive session (ssh, then command). Try echo $PATH in both cases.
ssh myremoteserver 'echo $PATH'
vs
ssh myremoteserver
[myuser#myremoteserver~]$: echo $PATH
If they differ, look in all startup script for some differentiated behavior based on $PS1 or $-