This question already has answers here:
Get output from a Paramiko SSH exec_command continuously
(6 answers)
Closed 11 months ago.
I am having an issue with getting my python script to return or print any output for the following command run on my fortigate firewall
'diagnose sniffer packet any "host X.X.X.X and port 53" 4 0 a
def dns_pcap():
device = ConnectHandler(device_type="fortinet", ip="X.X.X.X", username="xxxxxxxx", password="xxxxxxxxx")
lines = []
gi_pcap = device.send_command('diagnose sniffer packet GI "host X.X.X>X and port 53" 4 0 a')
output = device.read_channel()
print(output)
dns_pcap()
The script outputs nothing to my terminal, anyone have any idea how to get the output of this to command to print to my screen?
(Also please note I am using python2.7)
I have many scripts running to both fortinet and cisco devices, and they all print outputs from variable assigned commands to screen when i execute my scripts, but not in this case
I am assuming it is because the output is not static like a 'show system interface' but I am not sure how to handle dynamic output from a command.
The output is the result of the method device.send_command. output = device.read_channel() is not necessary. Replace print(output) with print(gi_pcap) and you'll be on the right track.
If the command requires any sort of interaction, that can also cause it to freeze up because the script is waiting for a prompt that will never come. You can see if this is happening by saving the session log output. You can do this by adding session_log="device.txt" to your session arguments, with device.txt being any filename relevant to you. The contents of that file will be whatever is being sent back and forth in the SSH session to the device.
The answer was indeed found in this post
Get output from a Paramiko SSH exec_command continuously
using paramiko and the get_pty=True argument in the function allowed me to print the pseudu terminal
Thanks very much to Richard Dodson for the help
Can you share what is the interval time of getting an output in your Fortigate device for this command? Depending on the interval time, netmiko should have also worked.
What I have also tested in a different vendor using Netmiko for an dynamic output that I tried to get data in 10 seconds interval (Totally 100 seconds), it worked without an issue, I was able to get the output properly. However, when I have increased time of the interval of getting data as 11 or 12, I get some errors so it did not work.
Can you also try with Netmiko "timing" method to get your data? If the interval is shorter than 1-2 seconds, this method should also help. (For example, I can get ping output with 100 count without an error using timing method. Did you also try to get ping output in your network box if it works?)
I think that the size of the data you expect from your output is also important in your case. If the size is too big to be shown in a CLI screen, this may cause also a problem. In that case, you might need to open a file to save your data and use it from that file might be another option.
Better if you can advise if there is a regular time interval of this command along with the expected size of the data.
In addition, what I have also figure it out that in case the output takes more than 100 seconds, it might cause the problem. Here is the sample of how to this option following:
{
'device_type': 'device_type',
'ip': '135.243.92.119',
'username': 'admin',
'password': 'admin',
'port': port,
"fast_cli": False, # fast_cli
"global_delay_factor": 2 # if the outputs takes more than 100 seconds.
}
Related
I am trying to use python 3.10.9 on windows to create a telnet session using telnetlib, but I have trouble to read the complete response.
I create a telnet session like
session = telnetlib.Telnet(host, port, timeout)
and then I write a command like
session.write(command + b"\n")
and then I wait some really long time (like 5 seconds) before I try to read the response using
session.read_some()
but I only get half of the response back!
The complete response is e.g.
Invalid arguments
Usage: $IMU,START,<SAMPLING_RATE>,<OUTPUT_RATE>
where SAMPLING_RATE = [1 : 1000] in Hz
OUTPUT_RATE = [1 : SAMPLING_RATE] in Hz
but all I read is the following:
b'\x1b[0GInvalid arguments\r\n\r\nUsage: $IMU,START,<'
More than half of the response is missing! How to read the complete response in a non-blocking way?
Other strange read methods:
read_all: blocking
read_eager: same issue
read_very_eager: sometimes works, sometimes not. Seems to contain a repetition of the message ...
read_lazy: does not read anything
read_very_lazy: does not read anything
I have not the slightest idea what all these different read methods are for. The documentation is not helping at all.
But read_very_eager seems to work sometimes. But sometimes I get a response like
F
FI
FIL
FILT
FILTE
FILTER
and so on. But I am reading only once, not adding the output myself!
Maybe there is a more simple-to-use module I can use instead if telnetlib?
Have you tried read_all(), or any of the other read_* options available?
Available functions here.
I have a python configuration script, the problem occurs when I import readline library and enter the console of the device. I get the input from the user this way:
val = input(display_str).strip()
This piece of code works perfectly but in the console of the device, long strings are not formatted properly and looks like it puts a limitation how long the string is and prints then on top of each-other. This makes the string unreadable and looks like this:
D/E,GATEWAY or N to delete : in format A:B:C:D:E:F:G:H/K,GATEWAY A:A:B:B:C:C:D:D
when in reality it needs to be formatted like this:
Enter eth1 IPv6 static routes in format A:B:C:D:E:F:G:H/K,GATEWAY A:A:B:B:C:C:D:D/E,GATEWAY or N to delete :
The formatting works perfectly when I ssh or use monitor but when I connect with console it mixes. When I remove the library everything works smoothly.
I found another solution to this problem which is using:
sys.stdout.write(display_str)
val = input().strip()
However here another problem occurs, the user can move left to the beginning of the string and delete the display_str and is not suitable. Other than then it works normally in every mode. Is there a solution for the input function or for the sys.stdout
I am setting up a remote SSH connection to a remote server and running a specific command to dump a DB table. The remote server is a hardened linux OS with it's own shell. I am running a remote sql type of command to dump out a lot of data. My python script is using an interactive SSH session to do this. As you can see below, I am running a command, letting it sleep for 5 seconds, then dumping the buffer. I've tried many different options for the "remote_conn.recv()" function but I cannot get the full output. The output is very large and it is paged (press space for more). I am not even getting the complete output of the first page. If there are 50 lines on the first page, I'm getting the first 4 only.
Are there better ways of doing this? How I can just grab the complete output? Below is the Paramiko portion of my script.
# Create instance of SSHClient object
remote_conn_pre = paramiko.SSHClient()
# Automatically add untrusted hosts
remote_conn_pre.set_missing_host_key_policy(
paramiko.AutoAddPolicy())
# initiate SSH connection
remote_conn_pre.connect(options.ip, username=options.userName, password=options.password)
# Use invoke_shell to establish an 'interactive session'
remote_conn = remote_conn_pre.invoke_shell()
remote_conn.send("<remote sql command here>")
time.sleep(5)
output = remote_conn.recv(65535)
print output
remote_conn.close()
I was able to get the full output by grabbing smaller chunks of the buffer and concat'ing them together until I hit a certain string in the buffer.
while True:
data = remote_conn.recv(500)
if "<string>" in data:
break
else:
finalOutput += data
I'm new to Python and i'm looking to run multiple parallel ssh connections and commands to the devices. I'm using pssh link for it.
Issue is the device returns some big header after the connection like 20-30 lines.
When i use the below code what is printed out is the result of the command but at the top there's also the big header that is printed after the login.
hosts = ['XX.XXX.XX.XXX']
client = ParallelSSHClient(hosts, user='XXXX', password='XXXXX')
output = client.run_command('command')
for host in output:
for line in output[host]['stdout']:
print line
Anyway i can get JUST the command output ?
Not sure I understand what you mean.
I'm using pssh as well, and seems like I'm using the same method as you are in order to print my command's output, see below:
client = pssh.ParallelSSHClient(nodes, pool_size=args.batch, timeout=10, num_retries=1)
output = client.run_command(command, sudo=True)
for node in output:
for line in output[node]['stdout']:
print '[{0}] {1}'.format(node, line)
Could you elaborate a bit more? Maybe provide an example of a command you run and the output you get?
checkout pssh.
This tool uses multi-threads and performs quickly.
you can read more about it here.
Bottom-Line
The script does not print everything from socket.recv() to the linux terminal.
If I do the same thing in the interpreter, it prints all the data to the terminal.
(let's say i use local gateway for ip and 23 for port, so telnetting into my router)
import socket
q = socket.socket()
q.connect(ip, port)
data = q.recv(1024)
print data
Output in interpreter is four lines:
(some alt-code gibberish or whatever on the first line)
RT v24-sp2 std (c) 2012 NewMedia-NET GmbH
Release: 03/21/12 (SVN revision: 18795)
DD-WRT login:
Output from script:
(just the alt-code gibberish from the first line)
Any advice regarding why this is happening and how to correct it would be greatly appreciated.
Thanks,
Andrew
When running the commands slowly one at a time, your router has time to send everything it's planning to send before you have a chance to invoke q.recv(1024).
When you run it from a script, the commands execute in quick succession. When the script executes q.recv(1024), the router has only managed to send some data, not all of it.
Since you do not use a loop to go back and try reading more data, that's the end, you will not receive (or print) any more data.
(By the way, what in the world is "alt-code gibberish"? What you should be getting here is some binary data that's part of the telnet protocol negotiation.)