Scripting SSH Connections to Extract Info from Output
-
@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.
-
That might work. I'm not very expert with expect. Although what are the chances that expect is installed?
-
@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
Basically. This client has some Cisco guys who are the admins and we basically report to them as the point of contact with the customer. I agree that keys would be better, but there are literally over 1000 devices between two of this company's stores, and they'd have to setup keys for over a dozen people to each device. Is there any easy or feasible way to do that. Right now we use AD creds to authenticate, which I assume are part of a group with just authentication rights to those devices.
-
@scottalanmiller said:
That might work. I'm not very expert with expect. Although what are the chances that expect is installed?
I typed "expect" into the CLI and got this:
expect1.1>So I assume it is.
-
@handsofqwerty said:
....but there are literally over 1000 devices between two of this company's stores, and they'd have to setup keys for over a dozen people to each device. Is there any easy or feasible way to do that.
More importantly, is there any feasible way not to? What could be better than having the right keys? If you have password access to the devices already, it would take almost no effort to deploy keys and lock down the shared passwords.
The more devices you have and the more people with access to them, the more important it is to be secure and to know who is doing what.
-
@handsofqwerty said:
@scottalanmiller said:
That might work. I'm not very expert with expect. Although what are the chances that expect is installed?
I typed "expect" into the CLI and got this:
expect1.1>So I assume it is.
Looks that way!
-
I know I'm a bit late to this conversation, but I think Ansible would quite possibly be a good candidate for this task. You could add your list of IPs to Ansible's host config file under a specified group and use Ansible's CLI to run a single command against every host in that group simultaneously or at a specified interval.
Ansible uses SSH for pretty much everything it does, so if the credentials are the same for all hosts I believe it will cache them and use them with each host without prompting multiple times. Just another avenue to consider.
-
@RamblingBiped said:
I know I'm a bit late to this conversation, but I think Ansible would quite possibly be a good candidate for this task. You could add your list of IPs to Ansible's host config file under a specified group and use Ansible's CLI to run a single command against every host in that group simultaneously or at a specified interval.
Ansible uses SSH for pretty much everything it does, so if the credentials are the same for all hosts I believe it will cache them and use them with each host without prompting multiple times. Just another avenue to consider.
I think normally you would just manually add a key for Ansible or build that into the image.
-
@scottalanmiller Yeah, that would be the ideal situation. Since that isn't an option though, he could easily override the default key-based auth and just use password authentication by adding the "--ask-pass" option to the manual command entry. If it fit the bill he could go a bit further and completely automate it by building a task/playbook.
I've been trying to incorporate Ansible into some of my routine tasks and really like it so far. I can definitely see it being a huge time saver for us in the future as we grow.
-
I want to play around with Ansible. I use Chef daily now and was using cfEngine all year last year. Did not like cfEngine. Chef is quirky and complex but does the trick better than cfEngine. Would love lots of free time to play with Puppet and Ansible to compare.
Are you using Tower or the free open source Ansible?
