PLINK - Sending Break Without Ending Session

[rm4453]

Hello,

 

I am attempting to run several commands via Plink, *Traceroute, Ping, Cat a file, and Sed it*.

I would like to break out of the traceroute after 3 failed hops ("***" -> 3Xs).

However whenever I send ^C it does nothing, and when testing with a Plink window via regular CMD if I press Control+C it ends my SSH connection.

I have not been able to find any combination of characters that would essentially send a Break to the current command being processed.

 

I have the SSH connection stable, I am able to perform Traceroute, Ping, Cat, & Sed commands required. I just don't want to force the user to wait for all 30 hops to fail etc.

[SlackerAl]

Plink is non-interactive, so you have two options: Use putty and interact with it or plink your commands one at a time, interrogate the output of each command and kill the plink process / update next command appropriately. My default choice is always plink unless the user actually needs to interact with the session. Of course a single session is faster and more efficient, so consider that if you are going to run this frequently (e.g. traceroute first, then if it works, bunch up the rest into a single plink). Here is a typical way I monitor plink output:

Func ExtractFromPlink($sRequest)
    
  Local $sConnection = "plink.exe -ssh -no-antispoof " & $sHost & " -P " & $sPort & " -l " & $sUserName & " -pw " & $sUserPassword
  Local $sCommand = " " & $sRequest & " ; sleep 1" ; sleep prevents truncation of output by fast server disconnect
  Local $iPid = Run($sConnection & " " & $sCommand, '', @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
  Local $sStdoutRead, $sData
  
  While ProcessExists ($iPid)
    $sStdoutRead = StdoutRead ($iPid)
    If Not @error And $sStdoutRead <> '' Then
      ; you can watch the output as it happens here, eg for error traps
      $sData &= $sStdoutRead
    EndIf
    If @error Then ExitLoop
  Wend
  
  return $sData ; returns the full plink command output
    
EndFunc   ;==>ExtractFromPlink

 

Note on security:

Using the above code, the user password is visible as plain text in the process table while plink is running (process explorer etc). Your alternative is to use an ssh key, but anyone who has access to the key then has password-less access to the server... Obviously, you can take steps to protect an SSH key - it all comes down to how much effort you want to put in versus the potential risk. I add this note not so much for the OP, but for anyone else referencing this.

Edited March 5, 2020 by SlackerAl
Note on security

[rm4453]

4 hours ago, SlackerAl said:

Plink is non-interactive, so you have two options: Use putty and interact with it or plink your commands one at a time, interrogate the output of each command and kill the plink process / update next command appropriately. My default choice is always plink unless the user actually needs to interact with the session. Of course a single session is faster and more efficient, so consider that if you are going to run this frequently (e.g. traceroute first, then if it works, bunch up the rest into a single plink). Here is a typical way I monitor plink output:

Func ExtractFromPlink($sRequest)
    
  Local $sConnection = "plink.exe -ssh -no-antispoof " & $sHost & " -P " & $sPort & " -l " & $sUserName & " -pw " & $sUserPassword
  Local $sCommand = " " & $sRequest & " ; sleep 1" ; sleep prevents truncation of output by fast server disconnect
  Local $iPid = Run($sConnection & " " & $sCommand, '', @SW_HIDE, $STDERR_CHILD + $STDOUT_CHILD)
  Local $sStdoutRead, $sData
  
  While ProcessExists ($iPid)
    $sStdoutRead = StdoutRead ($iPid)
    If Not @error And $sStdoutRead <> '' Then
      ; you can watch the output as it happens here, eg for error traps
      $sData &= $sStdoutRead
    EndIf
    If @error Then ExitLoop
  Wend
  
  return $sData ; returns the full plink command output
    
EndFunc   ;==>ExtractFromPlink

 

Note on security:

Using the above code, the user password is visible as plain text in the process table while plink is running (process explorer etc). Your alternative is to use an ssh key, but anyone who has access to the key then has password-less access to the server... Obviously, you can take steps to protect an SSH key - it all comes down to how much effort you want to put in versus the potential risk. I add this note not so much for the OP, but for anyone else referencing this.

 

I ended up doing something similar, where I essentially checked in a loop if the *** were present and moved from there. Thank you very much, and I luckily don't have to deal with user creds as the server is using AD to authenticate when SSH is established via their logged in windows creds, if that makes sense... I appreciate the response, and was about to submit my solution when you sent this... (I know late on replying as work has been busy.) Your solution is much more everyone proof so I will not post mine, and will welcome any who need further clarification to comment etc...