Scripting SSH Connections to Extract Info from Output
-
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"; doneIt is very fast, very reliable, very secure and works with sudo for even better security.
-
@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...
-
I have no control over that, sadly.
-
@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.
-
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.
-
Install SSHPass to handle this.
-
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.
-
@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.
-
@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).
-
@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.
-
@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.
-
@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.)
-
@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?
-
@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.
-
@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.
-
So the customer makes IT decisions and all just do the work? So basicly everyone there is L1 techs and the customer is the IT director and systems engineer
-
@thecreativeone91 said:
So the customer makes IT decisions and all just do the work? So basicly everyone there is L1 techs and the customer is the IT director and systems engineer
That's definitely what that description means. Which is not an uncommon situation. They want the warm and fuzzies of a Cisco shop but don't trust them so keep them doing work only as a technicality.
-
What about just using expect? That's how most things that are designed to be interactive work when you need to script them.
