ssh to an IP supplied via user input
Inject show running-config command
Search the output of the command and look for specific parameters like ports, QoS, VTY lines, SMTP settings, IP helpers etc.
Output only if the predefined parameters are not in place
If I store the output of the ssh run in a variable, is there a method I can use for parsing through it and just go with endless if, elsif, and else statements? How would that look?
It can be in Python bash or Perl, doesn't matter to me really but I don't know how to structure the thing and then fill in the gaps and expand the script.
Here's where I imagine starting from
use Net::SSH2
use File::Slurp;
print "\nEnter command list filename: ";
my $commandlist = <STDIN>;
chomp($commandlist);
my #commandfile = read_file($commandlist, chomp => 1);
my $commandsize = #commandfile;
How would I store the output of the commands in a variable or a temporary file and parse through it with conditions?
This is a very broad question, and it is unclear exactly what is puzzling you
The documentation for
Net::SSH2
and
Net::SSH2::Channel
describes clearly how to open a channel, send commands to it, and receive the response
You ask how you could store the results of the command in a variable, but it would be very awkward to do anything else. Again, the documentation describes this clearly
I suggest that you try writing some working code and experiment with it. It will be much easier to help you when you have a specific question
Related
I am using Python's Paramiko library to SSH a remote machine and fetch some output from command-line. I see a lot of junk printing along with the actual output. How to get rid of this?
chan1.send("ls\n")
output = chan1.recv(1024).decode("utf-8")
print(output)
[u'Last login: Wed Oct 21 18:08:53 2015 from 172.16.200.77\r', u'\x1b[2J\x1b[1;1H[local]cli#BENU>enable', u'[local]cli#BENU#Configure',
I want to eliminate, [2J\x1b[1;1H and u from the output. They are junk.
It's not a junk. These are ANSI escape codes that are normally interpreted by a terminal client to pretty print the output.
If the server is correctly configured, you get these only, when you use an interactive terminal, in other words, if you requested a pseudo terminal for the session (what you should not, if you are automating the session).
The Paramiko automatically requests the pseudo terminal, if you used the SSHClient.invoke_shell, as that is supposed to be used for implementing an interactive terminal. See also How do I start a shell without terminal emulation in Python Paramiko?
If you automate an execution of remote commands, you better use the SSHClient.exec_command, which does not allocate the pseudo terminal by default (unless you override by the get_pty=True argument).
stdin, stdout, stderr = client.exec_command('ls')
See also What is the difference between exec_command and send with invoke_shell() on Paramiko?
Or as a workaround, see How can I remove the ANSI escape sequences from a string in python.
Though that's rather a hack and might not be sufficient. You might have other problems with the interactive terminal, not only the escape sequences.
You particularly are probably not interested in the "Last login" message and command-prompt (cli#BENU>) either. You do not get these with the exec_command.
If you need to use the "shell" channel due to some specific requirements or limitations of the server, note that it is technically possible to use the "shell" channel without the pseudo terminal. But Paramiko SSHClient.invoke_shell does not allow that. Instead, you can create the "shell" channel manually. See Can I call Channel.invoke_shell() without calling Channel.get_pty() beforehand, when NOT using Channel.exec_command().
And finally the u is not a part of the actual string value (note that it's outside the quotes). It's an indication that the string value is in the Unicode encoding. You want that!
This is actually not junk. The u before the string indicates that this is a unicode string. The \x1b[2J\x1b[1;1H is an escape sequence. I don't know exactly what it is supposed to do, but it appears to clear the screen when I print it out.
To see what I mean, try this code:
for string in output:
print string
I am currently stuck with a situation where i need to hide the resolved value of a variable, i.e., the value should not appear when the code runs in the debug mode i.e., ksh -x.
I have seen other threads on similar kind of problem but there, a way has been provided when the value is read from STDIN, with the help of read -s option. But i do not have to read the value from STDIN.
Kindly help me with this.
Thanks,
Amit
When the field to be hidden is unique (something like a strong password), you can make a wrapper that changes the output of the script.
You should only take care for the special characters in the variable such as a slash. Try something like
mycode.sh 2>&1 | sed "s/${myvar}/xxxxxxxx/g"
When you use the variable on a few places only, a good alternative is testing the mode you are running in, and turn off the debug mode before using the variable (and turn on one line later).
I'd like to create utility that should be able to listen standard input and stream to standard output. Moreover I'd like to get command line arguments passed to utility. Is it possible to do with haxe/cpp environment?
What "trace()" exactly do? Can I override it's auto CR/LF with some ascii control characters to print pseudographical activity gauges?
I think that the trace function is inteded to be used only for debug, i think that's why it prints the file and the row from which you called it.
What I think you really want is Lib.print() and Lib.printl() to write something to the console.
For reading I didn't find a function as easy as that, but it's still easy enough, here's an example:
var stdin = Sys.stdin();
var string : String = stdin.readLine();
If you want to look more into console development in haxe I'd suggest you to look into some projects that uses them, for example to write this question I've read this file https://github.com/ianxm/ihx/blob/master/src/ihx/ConsoleReader.hx
Let's say I have in a Rails controller:
dir = params[:dir]
output = %x[ls #{dir}]
This is a HUGE security hole if somebody posts dir="foo; rm -rf /"
So I need to secure the parameter. I know I could do
system "ls", dir
But this method does not capture stdout !
So, how can I securely pass parameters to %x[] ?
The problem is that %x() basically hands a string to the shell to be parsed so you'd have to escape everything that the shell could possibly interpret. So %x is pretty much out the window if you need to deal with anything that you haven't built yourself (and event then it is suspect).
One solution is to use Open3.capture3:
out, err, status = Open3.capture3('/bin/ls', dir)
and then deal with the standard output (out) and standard error (err) returns as needed. There are a few other things in Open3 that might serve your needs better.
Have you looked at Ruby's safe levels?
http://www.ruby-doc.org/docs/ProgrammingRuby/html/taint.html
For levels >= 2 it says "Can't change, make, or remove directories, or use chroot."
There also used to be a sandbox gem, but I'm not sure if that's still active. You also could have a look at the source of "Try Ruby!" there has to be some kind of sandboxing in there.
I have a small python script to make an installation. I need some information like username, password, path, classname, dbname, ip, port etc... First of all this is an admin task and end-users won't be dealing with this script. So for an administrator should I ask every needed information with console prompts or just mention them in readme file then he can go and change variable assignments in script file (which are on top with needed explanation).
Asking for every possible information is for me kinda chatty. And other approach might be a bit hidden... Yes, at this point I need ideas...
I think either through command line arguments, like
$ foo john password -p 1977 -h 255.255.255.0
Or, if there's simply too much information, filing it in the script is a much better idea, as you only have to do it once, and the script is less complex as a result (no stdin code).
Depending on how you distribute the script, you code have a config file with it, like '.foo_config', and get the config from there, that's much more explicit, but not as simple to distribute.