nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Taft <a...@adamtaft.com>
Subject Re: remote command execution via SSH?
Date Wed, 25 Nov 2015 04:19:41 GMT
Sumo,

On Tue, Nov 24, 2015 at 10:27 PM, Sumanth Chinthagunta <xmlking@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message