Quote:
Originally Posted by
Corona688
expect is an ugly, last-resort solution for things that won't cooperate any other way, and tends to make insecure and unreliable solutions. If you think ssh can't be automated without it, you've learned the wrong lesson; there's a much better and more secure method built into ssh itself: authorized keys. It doesn't make much sense to say "my account policy says I can't automate this; therefore I'll automate it anyway, avoid the proper way since that's not allowed, and use the least secure and most contrived way imaginable instead!" Somehow I don't think that's what their security policy had in mind.
Hi Corona, I think you got it wrong. I did mention that I knew authorized keys already (and I have been using it quite a while), but in my opinion it is not automation as expect (yes, I thought it wrong you may think), and that I did not hear of expect before.
Anyway, let us try not to diverge the main question of my post: how to fool ps or hide password in my script.
Thanks,
D.
---------- Post updated at 06:08 PM ---------- Previous update was at 06:02 PM ----------
Quote:
Originally Posted by
virgil
1. Put the script in a separate expect script file, and use your bash script as a wrapper script. From bash, call the expect file. This will prevent the expect commands from appearing in ps.
Yes, I did. I tried it before combining my scripts to the script I posted. And the password still showed with ps.
Quote:
Originally Posted by
virgil
2. Instead of hardcoding the password in the file, store the password in a separate file and protect the file so that only the authorised users can access it.
I thought of this already, and it actually is a solution that a lot people recommend instead of passing password through arguments. But the permission of the file can be easily change by root, hence can be seen easily right?
Quote:
Originally Posted by
virgil
3. Instead of using a password, encode the password algorithm instead. For example your password may be month-based, e.g. mypasswdJul2010, so put the algorithm in the code to generate it.
And finally the decoded pass will be still passed to the argument of ssh or expect, or we can pass the encoded one?
Thanks,
D.
---------- Post updated at 06:14 PM ---------- Previous update was at 06:08 PM ----------
Quote:
Originally Posted by
pludi
Yes, I was referring to argv[] manipulation. Using memset() on argv[1]
* works with Linux 2.6.22 (OpenSuSE) using a non-suid ps, and with ps run as root
* does not work on HP-UX 11.31 using a non-suid ps
* does not work on FreeBSD 8.0 using a non-suid ps (as root)
* does not work on OpenSolaris 2009.06 using a non-suid ps
Seems like it's not dependent on the permissions of ps, but rather on the system.
I found a post describing
similar method, but I have no idea how to apply this to change (or fake) the name of the built-in process (such as expect or ssh) given its pid. If somehow ssh (or its argument) can be changed (or faked) then it is the solution, I think.
D.
---------- Post updated at 06:18 PM ---------- Previous update was at 06:14 PM ----------
Quote:
Originally Posted by
alister
Hey, pludi:
memset() on the string pointed to by argv[1] works on osx 10.4.11, where modifying the pointer in argv[1] directly (as my code was doing) failed.
Incidentally, as an unprivileged user, copying the suid ps binary so that it is no longer suid seems to work fine. I only tested a few options, however, so it's possible there's a privileged code path that I did not visit, just waiting to blow things up, but if collecting the process info did not require privilege -- I took a brief peek at Apple's ps.c, and it's using sysctl to gather the info; so, not surprising that privilige is not required for that step -- I don't see what would.
Regards,
Alister
Hi Alister,
I tried your code (modifying argv[1]) and it did not work on 10.6.3 either. Do you mean modifying memset() can change output of ps for built-in processes (xterm, expect, ssh, bash...) in my first post?
Thanks,
D.