Shell Getting ssh password without expect(1) in a shell script

fnoyanisi

fnoyanisi

Hi there,

I am trying to automate an ssh login via a shell script, and having some issues. There are multiple servers to connect to and users should be able to login the remote machine by running the script file from the command line for any particular machine (without typing in any username/password). Hence, the username/password is store in the script file (and I know, this is insecure and not the preferred way but this is how that system works).

The problem is, the system does not have expect installed on it and I do not have the root privilages, so need to figure out a method to automate the login process. Normally, SSH does not read stdin so normal redirection does not work for this case.

Any sugestions are welcome
Thank in advance...
 
Even though you didn't directly comment on it any reason you're not using ssh keys for this? Do you not want to or can't perform a setup process of getting the key on the remote system?

If you can't use ssh keys can you build expect locally?
 
derekschrock said:
Even though you didn't directly comment on it any reason you're not using ssh keys for this? Do you not want to or can't perform a setup process of getting the key on the remote system?
Click to expand...

Number of remote machines are in dozens and the account on the main server, which is a gateway to all those remote machines, is used by multiple people. Think of a UNIX machine acting as a trusted accesspoint to small devices all running an embedded OS and located remotely (we keep deploying new "small devices" constantly, so not a fixed number number of devices sitting in the wild).

Using ssh keys seem a bit not pratical in this case.

derekschrock said:
If you can't use ssh keys can you build expect locally?
Click to expand...
As I pointed out, I do not have root privilages on the main UNIX machine, so cannot build anything on it.
 
fnoyanisi said:
Number of remote machines are in dozens and the account on the main server, which is a gateway to all those remote machines, is used by multiple people. Think of a UNIX machine acting as a trusted accesspoint to small devices all running an embedded OS and located remotely (we keep deploying new "small devices" constantly, so not a fixed number number of devices sitting in the wild).

Using ssh keys seem a bit not pratical in this case.
Click to expand...
Actually public / private SSH keys are perfect for this case. Since the users have to have an account on the system to connect through to the devices, a public / private key for each login would be much better than passwords stored in a script. FYI, we have a similar system at my company called "front" that serves the same purpose. It has dozens of people who have to login to it to connect to other devices in the field. Each user creates his / her own key pair and sends that public key to the admin on the box to be installed in ~/.ssh/ on his / her account. When they connect they get a menu, created by the admin, of the list of devices to which they can connect from "front". Those devices mostly all have the a second public key of for that person installed on them too. In some cases where the remote device won't allow set-up of a key simple passwords are used that the users are trusted with. We also use LDAP for auth. When the user leaves the company that user's accounts are locked in LDAP which instantly stops login to all login servers on which that user has an account.

We stopped using a single account for this as it is too insecure.
 
Last edited by a moderator:
I think you should strip down those jumpboxes as far as possible.

Create a ssh_config on each client (this could be done central) where you use the directive "ProxyCommand".
Code: 
Host target
Hostname ip-of-the-target
User individual-user-name-on-target-system
ProxyCommand ssh ip-of-jumpbox -W %h:%p   # Use this if your ssh-client-software support the "-W"-Parameter
ProxyCommand ssh ip-of-jumpbox nc %h %p    # Use this if you have no "-W"-Parameter and netcat on the jumpbox

If you are doing a "ssh ip-of-the-target" following happens:
  • Then the client first authenticates itself with a ssh-key to the jumpbox (but can not login and change anything).
  • Then the client speaks directly with the target-system - through the jumpbox (again use ssh-keys but one per each user).
This has the advantage that also sftp and scp works between the client and the target.

For stripping down the jumphost, you can use several options in the authorized_keys-File on the jumphost
  • no-tty
  • permitopen (here you HAVE TO use the "-W"-parameter)
  • command (here you also have to use the "-W"-parameter because nc is forbidden)

If you have any questions - don't hesitate to ask.
Regards
Markus
 
Last edited by a moderator:
wblock@ said:
I don't understand why using a key is not practical. Create one key just for that use.
Click to expand...
Devices are small 3G wireless coverage units, like these ones. We manage/troubleshoot these devices by connecting another SunOS server, and SSHing to individual device (we have IP address of each device and they operate in a WAN within operator's networks).

Problem is, these coverage units come directly from the vendor, preconfigured, and sold in retail stores. We only load some configuration data and creating a key on each units requires indivudual work for every one of them. This is my understanding... That's why I said using a key is not practical.
 
Did I understand it correctly: You can load a configuration on the devices, but don't do any other stuff?
No offense, but I can't imagine, that you couldn't do a little bit better.
Once you got the initial ssh-access you can do anything you need for further, secure, remote assistance, can't you?

So I would say until you secure each device handle it internally as "uninitialized" and use a solution for automating everything.
Is python runable on those devices? Probably you can use the agentless solution "Ansible" - this seems perfect, as all devices are from the same kind. You can "initialize" each device and from this point on you can support all of them with ease.

But if you don't want to use keys at all I think there is no (secure, businesslike, best-practiceslike) solution for this problem.
If yes, we could design a solution which is usable for you.

Regards
Markus
 
storvi_net said:
Did I understand it correctly: You can load a configuration on the devices, but don't do any other stuff?
No offense, but I can't imagine, that you couldn't do a little bit better.
Once you got the initial ssh-access you can do anything you need for further, secure, remote assistance, can't you?
Click to expand...
Configuration data is loaded via another software, not SSH. SSH is only required for troubleshooting.

Just to answer your question; we first do the required change in a template file and these files are post-processed in an offline software, whose output is an XML file, called as a Work Order (WO).Then, these WOs are imported into another network management software, which has access to those wireless 3G units on site, and new configuration is pushed onto the device automatically.

Since each device sold in retail stores is a potential trouble maker, a "SSH keys" solution requires SunOS server to be authenticated on each device individually, which is ineffective. We cannot make bulk changes or do not have access to OS running on the device through our network management interface.
 
You must log in or register to reply here.
Back
Top