Now I've got libssh2 built, the time has come to actually create something.
My goal is to have a reliable way to run a command (or group of commands) on a remote server, show the command's output, and allow the user to select part of that output to run another command, and so on. The commands will be predefined, so it's a kind of "specialized SSH session".
The first test was, obviously, running a command on a remote server. The example program ssh2_exec.c does it out of the box, so that's where I started. And I got success on first run.
However, I needed to run several commands. After googling it, I was overwhelmed by the lack of examples on how to do it, which led me to the conclusion it might not be such a simple task. So, I've decided to take a look at the protocol's RFCs, particularly RFC 4254, the Connection Protocol.
And I've found the info I was looking for here (my emphasis):
"Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program, or a subsystem with a host-independent name. Only one of these requests can succeed per channel".
So, this means the life cycle for multi-command execution is: 1) open a channel; 2) execute the command; 3) close the channel. Rinse. Repeat.
This means there'll be no way to maintain state between executions. E.g., if I run "cd logs" and then run "ls -lt | head -1", the second command won't be run in the logs directory. In order to get it to work I either need to run a single command-line "cd logs; ls -lt | head -1", or put these commands on a shell script and run it.
BTW, the second option applies to anything you might want to do on the remote host. Assuming you've got somewhere to write a file, you probably can maintain state.
My goal is to have a reliable way to run a command (or group of commands) on a remote server, show the command's output, and allow the user to select part of that output to run another command, and so on. The commands will be predefined, so it's a kind of "specialized SSH session".
The first test was, obviously, running a command on a remote server. The example program ssh2_exec.c does it out of the box, so that's where I started. And I got success on first run.
However, I needed to run several commands. After googling it, I was overwhelmed by the lack of examples on how to do it, which led me to the conclusion it might not be such a simple task. So, I've decided to take a look at the protocol's RFCs, particularly RFC 4254, the Connection Protocol.
And I've found the info I was looking for here (my emphasis):
"Once the session has been set up, a program is started at the remote end. The program can be a shell, an application program, or a subsystem with a host-independent name. Only one of these requests can succeed per channel".
So, this means the life cycle for multi-command execution is: 1) open a channel; 2) execute the command; 3) close the channel. Rinse. Repeat.
This means there'll be no way to maintain state between executions. E.g., if I run "cd logs" and then run "ls -lt | head -1", the second command won't be run in the logs directory. In order to get it to work I either need to run a single command-line "cd logs; ls -lt | head -1", or put these commands on a shell script and run it.
BTW, the second option applies to anything you might want to do on the remote host. Assuming you've got somewhere to write a file, you probably can maintain state.
No comments:
Post a Comment