EldoS | Feel safer!

Software components for data protection, secure storage and transfer

TEISimpleSSHClient.ExecuteCommand() -- no exceptions thrown?

Also by EldoS: CallbackProcess
A component to control process creation and termination in Windows and .NET applications.
#24364
Posted: 03/28/2013 15:23:25
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

I'm not seeing any errors or exceptions thrown from SimpleSSHClient.ExecuteCommand() when I would expect them.

For example, I can set the host property to a bogus ip address and not even get a socket exception, nor an error return from ExecuteCommand()

How is one supposed to know if there was an error executing the command?

(The only sign of a possible error is that the return value is an empty string, but what if the command you executed returns an empty string - how do you know the command was actually executed?)

Michael
#24365
Posted: 03/29/2013 01:05:05
by Vsevolod Ievgiienko (EldoS Corp.)

Hello.

ExecuteCommand() is a simplified method, so indeed it doesn't throw exceptions in all possible situations. Still a number of errors are reported via TElSimpleSSHClient.OnError event handler. If you need a full control over possible errors then you should use Open/SendData/ReceiveData/Close approach.
#24366
Posted: 03/29/2013 01:25:32
by Eugene Mayevski (EldoS Corp.)

To clarify on Vsevolod's answer - ExecuteCommand explicitly suppresses all exceptions. This is a design decision so if you need other behavior, use the approach Vsevolod mentioned.


Sincerely yours
Eugene Mayevski
#24368
Posted: 03/29/2013 04:02:14
by Ken Ivanov (EldoS Corp.)

To clarify both Eugene's and Vsevolod's answers - in fact, connectivity exceptions *are not* suppressed in the ExecuteCommand() method, so any problem the component happens to have on the negotiation stage will be reported by throwing an exception. However, the connectivity exceptions *are* suppressed in the debug assembly that we gave you a couple of days ago for investigative purposes, and they *will not* be in the future release version.
#24369
Posted: 03/29/2013 06:18:19
by Eugene Mayevski (EldoS Corp.)

In release version exceptions are suppressed after a call to Open(). I.e. if an exception happens during connection or SSH negotiation, you get an exception. If an exception happens during data transfer, you don't get an exception.


Sincerely yours
Eugene Mayevski
#24370
Posted: 03/29/2013 14:08:01
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

Gentlemen,
Just to confirm, here's what I'm seeing:

old assemblies: ExecuteCommand will throw certain errors (ie bad host address, good address but no ssh server, etc).

new assembly: ExecuteCommand does not throw any errors, even low level connection ones. It always completes.

A question then: going forward what will be the behavior? (One of you has suggested that the latter behavior will be the "new and permanent" behavior)

Michael
#24371
Posted: 03/29/2013 14:35:53
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

Also, does this mean that other "simple" client such as SFTP are not going to throw exceptions in all cases, such as for DownloadFile() and UploadFile()?

I have to say that I'm perplexed with your decision to have any library call (eg ssh simple client ExecuteCommand) swallow up exceptions and not report them. If an application wants to ignore exceptions, that's easy to do. But it can't "guess" when an exception should have been thrown and wasn't.

My application relies on the ability to sense ssh/sftp exceptions, so that the overall operation can be retried again. If your code is not throwing exceptions then this means I cannot rely on the return data from it, and I also cannot apply "retry" logic since I don't know there was an error.

The second problem is that this approach means your library semantics are inconsistent. Some library methods at the same semantic level (like simple sftp DownloadFile() and simple ssh ExecuteCommand) throw exceptions and others don't.

How is a developer to know which ones will throw exceptions and which ones won't? The help file text for these methods doesn't mention exception handling differences.

I can switch to the "regular" ssh client in order to "manually" execute remote commands (ie without the help of a higher level method such as ExecuteCommand) but now I'm wondering if exception handling is going to be consistent and work as expected in those methods??
#24372
Posted: 03/29/2013 14:50:40
by Eugene Mayevski (EldoS Corp.)

Quote
Michael Lovett wrote:
A question then: going forward what will be the behavior? (One of you has suggested that the latter behavior will be the "new and permanent" behavior)


I don't know why you came to this conclusion, but new release would behave in exactly the same way as the previous one did. What you are naming "new assembly" is a debug one which was given to you for checking your particular problem. This is not a release code and it works differently from the release.

Quote
Michael Lovett wrote:
Also, does this mean that other "simple" client such as SFTP are not going to throw exceptions in all cases, such as for DownloadFile() and UploadFile()?


Nope, this doesn't mean anything besides what was written above.

Quote
Michael Lovett wrote:
I have to say that I'm perplexed with your decision to have any library call (eg ssh simple client ExecuteCommand) swallow up exceptions and not report them


I am perplexed either because this is NOT what happens in reality. I don't know why you came to the idea that "any library call swallows exceptions" but it isn't so.

ExecuteCommand is a *very* high-level method which incapsulates all the functionality in one call. It was implemented for specific cases where exceptions are not important and/or are not expected to happen (or when the error can be detected by analysis of the data returned). In other words, if you don't like anything in ExecuteCommand, - just don't use this method but use Open/SendData/ReceiveData/Close sequence of calls.

In general, SecureBlackbox offers unprecedented flexibility and its classes and methods are of different complexity (and "compoundness"). With TElSSHClient you can do *anything* SSH defines, but you would have to write plenty of code. With SimpleSSHClient you don't need to bother about sockets, but this comes at a cost of having less flexibility. Still you have control over what you send and receive. Now, ExecuteCommand method is even more high-level as it does everything for you including exception handling. Again, if you don't like this, - just go down one or two levels and get more flexibility.


Sincerely yours
Eugene Mayevski
#24373
Posted: 03/29/2013 14:58:32
by Ken Ivanov (EldoS Corp.)

Michael,

Please check my reply to you in your Helpdesk ticket. The behaviour exposed by the debug assembly I've attached there is more or less what you will get in the official SecureBlackbox update.

Quote
Also, does this mean that other "simple" client such as SFTP are not going to throw exceptions in all cases, such as for DownloadFile() and UploadFile()?

No, absolutely not. Eugene's reply only concerned the ExecuteCommand() method and the behaviour specific to this particular method.

Quote
I have to say that I'm perplexed with your decision to have any library call (eg ssh simple client ExecuteCommand) swallow up exceptions and not report them. If an application wants to ignore exceptions, that's easy to do. But it can't "guess" when an exception should have been thrown and wasn't.

It is important to understand that not all exceptional situations are swallowed up by the ExecuteCommand() method (and I would like to stress once again that we are talking about this particular method, so it's not 'any library call' that suppresses them). So, to summarize:
- whenever an exceptional situation occurs during SSH negotiation (server address resolving, TCP/IP connection setup, key exchange and authentication), it *is* propagated to the user.
- whenever an exceptional situation occurs during command execution, it is reported via the OnError event. The exceptions are suppressed to let the user retrieve incomplete command output returned via the method parameters.
- there is also a CommandCompleted property that indicates whether a command finished 'legally' (on the server) or was interrupted by a connection breakdown.

Quote
The second problem is that this approach means your library semantics are inconsistent. Some library methods at the same semantic level (like simple sftp DownloadFile() and simple ssh ExecuteCommand) throw exceptions and others don't.

ExecuteCommand() is a sort of exceptional case here. We can't throw exceptions from it, as we need to preserve partial outputs of the command which can be of importance to the user. All the other higher-level methods throw exceptions in accordance with relevant good practices.

Quote
How is a developer to know which ones will throw exceptions and which ones won't? The help file text for these methods doesn't mention exception handling differences.

A general rule is that synchronous components and methods (such as TElSimpleSFTPClient.DownloadFile()) will throw exceptions should a problem occur during their execution. Asynchronous components and methods (e.g. TElSSHClient.Open) MAY throw exceptions to report erroneous situations 'known' at the time of method invocation (e.g. caused by component misconfiguration), yet protocol errors will be reported via different means - most often, via the OnError event.

Quote
I can switch to the "regular" ssh client in order to "manually" execute remote commands (ie without the help of a higher level method such as ExecuteCommand) but now I'm wondering if exception handling is going to be consistent and work as expected in those methods??

It is. However, I suggest that you first try the assembly I've attached to your Helpdesk ticket and check if its behaviour is acceptable for you.
#24380
Posted: 03/30/2013 17:14:13
by Michael Lovett (Standard support level)
Joined: 03/20/2013
Posts: 28

Thanks to all for your replies. I realized today that I read one of your earlier posts wrong, and so my response was a bit off base, and that threw us on a bit of a wild goose chase. That, plus differing opinions from the Eldos responders on what exceptions ExcecuteCommand does and doesn't throw, has created some confusion.

Also, I did not realize until your recent replies to this thread that the first special assembly you sent worked differently in this regard; that also added to confusion about how ExecuteCommand works in regard to error handling.

I'd like to see if we can press "reset" on this thread for the sake of moving forward. Summarizing the above, here's what I think I'm hearing:

The production version ExecuteCommand (now and any future ones) throws connection related exceptions, but once a connection is established, other errors (ie protocol errors) are reported via OnError only.

Right?

I see that you have sent me another assembly (associated with the ticket) and that one will act more like the production code I just described (ie will throw connection exceptions and use OnError for reporting other errors). I will respond to the ticket with any questions I have specifically related to that assembly since those questions would not be of interest to the general public.

One last thing I would like to clear up on this thread, though, is the "division of errors" (my wording) reported via exception vs those reported via OnError.

My understanding is that all errors that prohibit establishing a successful connection are going to be reported via exception (for all the methods/components involved in this conversation). After that point, "protocol level" errors are not reported by exception, but only by OnError.

(Is this all right so far?)

If that's the case, I guess my question is this: do any of the "protocol level" errors that are reported via OnError signify that the operation has failed? .. or are the kinds of errors reported by OnError "lessor errors" that the Eldos library was able to recover from?

Ultimately I need to know conclusively in my app whether or not an operation failed (at any point) and what I need to do to sense this; do I need to monitor both exceptions and OnError, or just exceptions?

Sorry if it seems like I'm beating a dead-horse, this is just something that's not yet clear to me.

Thanks for your time, guys.
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 2873 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!