Scripting SSH Connections to Extract Info from Output

handsofqwerty

So here is the scenario...

I need a way, on Ubuntu, to SSH into multiple devices (script it to run one at a time against a list), preferably with a password in the command, run one command, and exit. Right now I got the command working, but it prompts for a password each time, and you have to enter each IP manually. I'm sure you can use a list using a variable or a shell script somehow but I wasn't sure how you'd do it. Basically this is the command:

ssh domain/username@IP 'show int <interface> | inc <info to extract>'

So what I need is a way to include a password in the command and use a variable to run the command against a list of IPs. We can log the output to a text/log file. That's fine. If there was a way to do it to a CSV, that'd be even better. This is a sample output:

						 ACCESS OF A PRIVATE SYSTEM
<banner message>
  Description: <ISP> CKT ID: <the circuit ID here>

Thanks!

scottalanmiller

Make a list called serverlist. Then do this...

for i in $(cat serverlist); do whatever; done

scottalanmiller

An SSH password? Why is there a password being passed in a script? That kind of defeats the purpose. Use SSH keys instead. No password needed, far more secure.

scottalanmiller

We do this all of the time from our jump server. To get the uptime of every UNIX box I can just run...

for i in $(cat serverlist); do ssh -qt "$i" "sudo uptime"; done

It is very fast, very reliable, very secure and works with sudo for even better security.

handsofqwerty

@scottalanmiller said:

An SSH password? Why is there a password being passed in a script? That kind of defeats the purpose. Use SSH keys instead. No password needed, far more secure.

We're remoting into a Cisco device, so I don't know if that even supports keys, and this is the way we do it with this client. I can't do much about that, so we need a way to pass a password through the command if we can...

handsofqwerty

I have no control over that, sadly.

scottalanmiller

@handsofqwerty said:

@scottalanmiller said:

An SSH password? Why is there a password being passed in a script? That kind of defeats the purpose. Use SSH keys instead. No password needed, far more secure.

We're remoting into a Cisco device, so I don't know if that even supports keys, and this is the way we do it with this client. I can't do much about that, so we need a way to pass a password through the command if we can...

That would be insanely sad for Cisco security if they did not.

This is REALLY insecure. The client should be furious if they were to find this out. Putting passwords into scripts is pretty nuts. That means not only is it being put into text on screen for no reason and the security of the connection reduced but it is also being saved in the shell history and put on disk over and over again.

Cisco IOS v12.0 or newer supports ssh keys. Which is basically any version of IOS that supports ssh.

scottalanmiller

Yeah, did a quick search and how tos on it are everywhere. It's just normal SSH and is the same as any other system.

scottalanmiller

Install SSHPass to handle this.

scottalanmiller

Just for reference, when you get upset with the ridiculous things that @Lakshmana's boss makes him do, this is one of those. This should trigger an audit of the "Cisco experts" that they have working there. No first day networking guy would do this or let anyone in the shop do this. This means, to me, there isn't one junior networking level, or higher, person in the shop. This is a high school level mistake. No consulting firm, anywhere, should ever have this happen. An L0 might do this, but anyone at L1 helpdesk or higher should know never to do this. So whoever set this up, and whoever oversees those people and whoever makes the hierarchy all screwed up royally.

handsofqwerty

@scottalanmiller said:

Just for reference, when you get upset with the ridiculous things that @Lakshmana's boss makes him do, this is one of those. This should trigger an audit of the "Cisco experts" that they have working there. No first day networking guy would do this or let anyone in the shop do this. This means, to me, there isn't one junior networking level, or higher, person in the shop. This is a high school level mistake. No consulting firm, anywhere, should ever have this happen. An L0 might do this, but anyone at L1 helpdesk or higher should know never to do this. So whoever set this up, and whoever oversees those people and whoever makes the hierarchy all screwed up royally.

Not my call. Maybe it was recommended, maybe not. I have no way of knowing. Maybe the customer didn't want it. Again, I have no way of knowing.

handsofqwerty

@scottalanmiller said:

Install SSHPass to handle this.

Yeah, I saw this. They'd have to get permission from the customer to install it on their monitoring box (even though it's our appliance that we designed).

handsofqwerty

@scottalanmiller said:

@handsofqwerty said:

@scottalanmiller said:

An SSH password? Why is there a password being passed in a script? That kind of defeats the purpose. Use SSH keys instead. No password needed, far more secure.

We're remoting into a Cisco device, so I don't know if that even supports keys, and this is the way we do it with this client. I can't do much about that, so we need a way to pass a password through the command if we can...

That would be insanely sad for Cisco security if they did not.

This is REALLY insecure. The client should be furious if they were to find this out. Putting passwords into scripts is pretty nuts. That means not only is it being put into text on screen for no reason and the security of the connection reduced but it is also being saved in the shell history and put on disk over and over again.

Yeah, well, this is what I have to work with. Again, if I was running it, I could have us setup keys, but it's not my call. I use keys for all my servers, and never SSH into any server directly anymore. I jump to my jump server and go from there, because I have keys setup from there.

@scottalanmiller said:

Just for reference, when you get upset with the ridiculous things that @Lakshmana's boss makes him do, this is one of those. This should trigger an audit of the "Cisco experts" that they have working there. No first day networking guy would do this or let anyone in the shop do this. This means, to me, there isn't one junior networking level, or higher, person in the shop. This is a high school level mistake. No consulting firm, anywhere, should ever have this happen. An L0 might do this, but anyone at L1 helpdesk or higher should know never to do this. So whoever set this up, and whoever oversees those people and whoever makes the hierarchy all screwed up royally.

Especially if SSH is open over WAN for the routers this is a major mistake. And it often is open over the WAN. This is essentially giving someone access to the whole network.

scottalanmiller

@handsofqwerty said:

Not my call. Maybe it was recommended, maybe not. I have no way of knowing. Maybe the customer didn't want it. Again, I have no way of knowing.

Not @Lakshmana's call either. You see my point? This is "having the work outsourced to scammers in India" level of failure. But it isn't your call. Remember that when people are forced to do things to screw customers.

scottalanmiller

@handsofqwerty said:

Not my call. Maybe it was recommended, maybe not. I have no way of knowing. Maybe the customer didn't want it. Again, I have no way of knowing.

The customer would only not have wanted it if there was no consultant with the skill to explain the situation. (e.g. no qualified entry level consultants.)

scottalanmiller

@handsofqwerty said:

@scottalanmiller said:

Install SSHPass to handle this.

Yeah, I saw this. They'd have to get permission from the customer to install it on their monitoring box (even though it's our appliance that we designed).

So the customer is blocking security AND productivity?

handsofqwerty

@scottalanmiller said:

@handsofqwerty said:

@scottalanmiller said:

Install SSHPass to handle this.

Yeah, I saw this. They'd have to get permission from the customer to install it on their monitoring box (even though it's our appliance that we designed).

So the customer is blocking security AND productivity?

We designed the system, but once we deploy it to the customer, we have to have permission to make ANY changes to it. Even to change monitoring on devices that we know have changed (interface monitoring, etc), we have to create a request and they have to approve it. It seems very convoluted to me but that's the procedure here. I'm not in a position to try and fix business practices at this point.

scottalanmiller

@handsofqwerty said:

@scottalanmiller said:

@handsofqwerty said:

@scottalanmiller said:

Install SSHPass to handle this.

Yeah, I saw this. They'd have to get permission from the customer to install it on their monitoring box (even though it's our appliance that we designed).

So the customer is blocking security AND productivity?

We designed the system, but once we deploy it to the customer, we have to have permission to make ANY changes to it. Even to change monitoring on devices that we know have changed (interface monitoring, etc), we have to create a request and they have to approve it. It seems very convoluted to me but that's the procedure here. I'm not in a position to try and fix business practices at this point.

Which we understand. Just keep in mind that this is a failure on par with those that you've been rather upset about in the past.