What I'm looking for: how to create a script that will execute su, provide a password, and let me stay in that new shell.

What I've found on google: lots and lots about how to execute an operation but nothing on how to stay in the shell

What I've got so far which does work, but immediately logs me out of the new shell (this may not even be the right approach, please tell me if it's not):

**********************
#!/usr/bin/expect
set user "<username>"
set pass "<password>"

spawn su - $user
expect {
;Password: {send "$pass\r"; exp_continue};}
**********************

Security concerns: This file lives in a secured directory so no other users (except the sysadmin obviously) can view the file.

Situation: I have to work with over 100 boxes, I can't use my account to perform operations with the applications we have living on them - hence the su, we are suddenly no longer able to log in directly to the application account, our passwords are ridiculously long and this is going to add a lot of unnecessary typing to my and my team's day if I can't get this script to work so I look forward to your suggestions here!

I had a similar situation and what I did was create a user "sshadmin" and setup ssh-key auth to the systems and then add them to the sudoers with nopassword. This sshadmin user was locked down to a jumpbox only my sys admin team had access to. So we would authenticate to the jumpbox then I wrote a simple script called "sshadmin" that would initiate an SSH connection to whatever hostname was provided as an argument. It logged all the ssh sessions under an appendable only directory for logging/audit purposes so users on the jumpbox couldnt remove the log files and they didnt have root so they couldnt chattr.

It worked well and since we had sshadmin user in the sudoers file with nopasswd we would just ssh to a box and sudo su -.


This is kind of an alternate solution to what you are looking to do, just some food for thought. If you want to go down this road I can send you some of the script info via a PM just let me know.

Hmm, it looks like that is an option and if I get no bites on the other solution then this may be the way to go, but let me share why I'm still hoping for the other solution. It's really an issue of sheer efficiency. The goal is to have the fewest obstacles between me and getting to my work as possible. Here's what's going through my mind (sorry if this doesn't format right):

1) script option

log in to box
./login.sh

2) your log in option

log in to box
ssh <newbox>
su - <account>
# also: I can do the script myself, and this solution gets impacted if this one host goes offline for any reason

So there's more steps involved in the login option, but only 1 so it's not really unacceptable, however there are a couple of other issues here. The biggest one is that I can do the script approach myself without having to deal with waiting for the sysadmin to find time to get to the other solution and then having to deal with him being cranky about me giving him more work Given the number of boxes I'm working with this sounds like it might turn into a lot of work for him. Also, there is the issue that now I'm pinned to that box and if it goes down for some reason (not common, but has happened - think networked storage that's not configured correctly etc.) I'm now back to typing everything in for awhile. So this is a great start, but I'm really hoping for a script solution - if that's even possible? If not I'll likely be sending you a pm haha

Looks like the answer was to replace "exp_continue" with "interact". Thanks for all your help!

1 members found this post helpful.