Yes, insecure if the password is written in the script, on the HDD, but what about if it in a variable, on the RAM, entered by the user at each login?

if you want to save that password and several invocations will use the same, stored string (if I understand it well) it will be insecure anyway either it was stored in hdd or ram or whatever. If your script can access it any other script will do too.

A variable where?

Is the script running or not? Seems like you re-run the script each time you wish to start a new session.There's no such thing as a RAM variable which you can access from a script or program unless it is 100% deterministic each time you enter the program or script. Meaning you have defined a specific memory address or a location on disk. And then having done that, what pan64 said is true, any other script or program can access this variable.

Maybe write an expect script, save it on an USB key and execute script from there, then try not to lose the key (or maybe crypt it)

Even then... The variables and environment CAN be obtained.

Part of the problem is that the password ends up in many places - the shell, expect, ssh,...

ssh goes to extreme lengths to prevent the password from being anywhere but inside ssh, even to the point of disabling the ptrace access (both to itself and to ssh-agent).

None of the other tools go to this length to prevent access.

Maybe it's acceptable for OP I mean he may be concerned only not to have the password stored on local disk.

Yes, the password variable can be accessible by any script of mine, just as long as it is unreachable by other users on logged on the linux machine (client).

UserA logs in the linux machine
UserA puts its password in VarX
UserA launches script.sh
script.sh launched by UserA can access VarX

UserB logs in the linux machine
UserB reads VarX, VarX has no content from UserA
UserB launches script.sh
script.sh launched by UserB cannot access VarX, because VarX has no content from UserA
UserB reads script.sh, script.sh contains UserA's username, but no password is embedded in script.sh

I was thinking of password stored in script and the script stored on external drive (usb key)
Now if the script is shared with other users, this plan won't work :/

This is rather difficult to achieve, you are defeating the purpose of having someone remember and type a password. If the script stays running and holds a previously entered password in a variable, this is one thing, to have some sort of system global memory of a password which is supposed to go away at some point, as yet not clearly defined, is difficult, barring on unrealistic, and clearly not so very secure anymore.

I sometimes say to people (about code and scripts):

"You can cute it up all you want, but is that really necessary?"

To whit: You write a program or script to fulfill functions that are complex, iterative, and save you typing; however when passwords are involved, the "user" of your program or script will question why it seemingly remembers their password and under which conditions it shall forget them, because ...

I'm not saying this task is unable to be accomplished. I am questioning the choice to do these actions, and I'll leave it at that.

Interesting, the users in question are technicians who could read the script if they questioned where the passwords are stored. Here is an example of what problem I am trying to bypass:

A user says it's dead phone is on the wall jack D-15 (local names for ethernet wall jacks in the compagny)
I seach the database and have no luck finding any record of D-15 (too many jacks, too may changes, the compagny did not keep up)
I search in the network switches for the interface descriptions using the hostnames specific to the location

ssh user@switch1
password
show interface description | i D-15
[no result]
exit

ssh user@switch2
password
show interface description | i D-15
[no result]
exit

ssh user@switch3
password
show interface description | i D-15
[no result]
exit

ssh user@switch4
password
show interface description | i D-15
[no result]
exit

ssh user@switch5
password
show interface description | i D-15
[no result]
exit

ssh user@switch6
password
show interface description | i D-15
Fa0/8 down down Jack D-15

That's a lot of User/password to enter to get there. Multiply that with the number of cases per day.
I can live with that, but I was hoping for a shortcut.
Thanks anyway for your opinion, I might use your idea of using Keys if I get to work on a small system (not hundreds) that I setup myself from scratch (not the case here)

Using ssh-copy-id to install your key in each Cisco is preferred.

Or you can put your passwords in a protected file and use sshpass to login so your password is not in a shell variable.

Don't forget swap.... Occasionally shell data does get swapped out, and that would put it on disk, unencrypted.

Again, that's kind of a textbook use case for ssh keys. If you want passwords, "sshpass" has been mentioned at least once above, that will read from a file. But keeping passwords around in clear text is likely to end in trouble. Yes, you'd have to put keys (the public key part of each key pair) on each of the remote machines. However, that is likely to save you work and make the whole process more secure. There is the cost of potentially having to change all the passwords to consider, too.

That aside...

One characteristic of SSH that could save you work in another way is that the client does pass back the exit code from the last command processed on the remote host.

So that last line would print out a zero, for success, if it's run this year.

And that would return a one, for failure.

Based on the example you gave, you could use that to automate the remote command.

The output of the remote command would still be shown as usual so the "echo" part is redundant, but you could change it to say the name of the remote device as well. Keys would speed that up the second and subsequent runs by handling the authentication automatically but securely.