I have first-cut implementation of ExecuteRemoteProcess processor at: https://github.com/xmlking/nifi-scripting/releases <https://github.com/xmlking/nifi-scripting/releases>
I tried to provide all capabilities offed by groovy-ssh (https://gradle-ssh-plugin.github.io/docs/ <https://gradle-ssh-plugin.github.io/docs/>) to ExecuteRemoteProcess user. it takes three attributes: 1. SSH Config DSL (run once on OnScheduled) remotes { web01 { role 'masterNode' host = '192.168.1.5' user = 'sumo' password = ‘fake' knownHosts = allowAnyHosts } web02 { host = '192.168.1.5' user = 'sumo' knownHosts = allowAnyHosts } } 2. Run DSL ( run on each onTrigger) ssh.run { session(ssh.remotes.web01) { result = execute 'uname -a' } } 3. User supplied Arguments which will be available in Run DSL anything that is assigned to ‘result’ in RunDSL is passed as flowfile to success relationship. Any suggestions for improvements are welcome. -Sumo > On Nov 24, 2015, at 8:19 PM, Adam Taft <a...@adamtaft.com> wrote: > > Sumo, > > On Tue, Nov 24, 2015 at 10:27 PM, Sumanth Chinthagunta <xmlk...@gmail.com> > wrote: > >> I think you guys may have configured password less login for SSH (keys?) >> > > Correct. I'm using SSH key exchange for authentication. It's usually > done password-less, true, but it doesn't necessarily have to be (if using > ssh-agent). > > > > >> In my case the edge node is managed by different team and they don’t >> allow me to add my SSH key. >> > > Yikes. Someone should teach them the benefits of ssh keys! :) > > > >> I am thinking we need ExecuteRemoteCommand processor (based on >> https://github.com/int128/groovy-ssh) that will take care of key or >> password base SSH login. >> > > +1 - this would be a pretty nice contribution. Recommend building the > processor and then posting here for review. I'm sure this would be a useful > processor for many people. > > > ExecuteRemoteCommand should have configurable attributes and return command >> output as flowfile >> >> host : Hostname or IP address. >> port : Port. Defaults to 22. >> user : User name. >> password: A password for password authentication. >> identity : A private key file for public-key authentication. >> execute - Execute a command. >> executeBackground - Execute a command in background. >> executeSudo - Execute a command with sudo support. >> shell - Execute a shell. >> >> > As we do for SSL contexts, it might make sense to bury some of these > properties in an SSH key controller service. I'm thinking username, > password, identity might make sense to have configured externally as a > service so they could be reused by multiple processors. Unsure though, > there might not be enough re-usability to really get the benefit. > > Also, I'm thinking that the "background", "sudo" and "shell" options should > possibly be a multi-valued option of the processor, not separate > properties, and definitely not separate "commands." i.e. I'd probably > recommend property configuration similar to ExecuteCommand, with options > for specifying the background, sudo, shell preference. > > Good idea, I hope this works out. > > Adam
