Fairly new to the System Admin world, and this is my first post here, hoping to get some clarification.
I am using a BASH script to automate some Logfile Archiving (into .tars). The actual logfiles are accessed through an SSH, so I have used the following EXPECT sub-script within my main BASH script (which includes tons of other stuff) :
expect - << EOF
spawn ssh $serverName
match_max 100000
expect -exact "$SIGNEDIN@$serverName\'s password: "
send -- "$PASS\r"
expect -exact "\[$SIGNEDIN@$serverName ~\]# "
send -- "cd /folder1/logfiles\r"
expect -exact "\[$SIGNEDIN@$serverName logfiles\]# "
send -- "tar -cvf logs.$serverName.$CURRENTDATE.tar *.log\r"
SLEEP 30s
expect -exact "\[$SIGNEDIN@$serverName logfiles\]# "
send -- "mv *.tar LOG_ARCHIVE\r"
expect -exact "\[$SIGNEDIN@$serverName logfiles\]# "
send -- "exit\r"
EOF
All of the variables are set earlier in the script and this is actually working exactly as it should . . . but only when the filesizes are small. Some of the servers have small logfiles and some have huge logfiles. The small ones finish long before the 30s SLEEP, but yet sometimes the 30s SLEEP is not long enough for the larger servers. This causes the "mv" command to run before it finishes, and then the whole process is shot. I could increase the SLEEP timer to an even larger number to make sure the "tar -cvf" command completes . . . . but I am already impatient enough. There has got to be a better way to do this.
Anyone please chime in with some ideas, I am willing to try anything (except keys, I cannot use keys)
ssh is designed to prevent you from using stored plaintext passwords, because they're very insecure; "interactive password authentication" means "password typed by a human being in realtime authentication" and nothing else will do. That's why you've had to use a third-party brute-forcing utility to make it work at all.
If you use ssh the proper way, with keys, you won't need to sledgehammer in an insecure plaintext password with a third-party brute-forcing utility like expect, and will be able to automate things far, far easier since it can take input exactly as given with no mess, and won't cough up its own skull when the remote script reacts in an even slightly unexpected way:
#!/bin/sh
ssh -i /path/to/keys username@server <<EOF
cd /folder1/logfiles
tar -cvf logs.$serverName.$CURRENTDATE.tar *.log
mv *.tar LOG_ARCHIVE
EOF
When using keys, it really is that simple, because you don't have to fight it.
google 'passwordless ssh' to find out how you're supposed to do it. There's hundreds of tutorials all over the internet.
1 Like
Wow, thanks for the quick response Corona. Do you get payed for this stuff, every single page I have been in today you are usually the first to respond 
.
I understand what you are saying, but it is not my call. They don't want keys, and I am not authorized to set up keys.
The users have this process, that is a very repetitive sign-in / .tar / sign-out over and over and over again for each server. This is a one use script, it is not something that is running constantly with a unsecured stored password. They wanted something that automates it while only needing one Sign-In/Password. I have the earlier section set up just like thier regular Sign-In/Password prompt. The password has echo off and is stored in $PASS only for the current session (which is closed afterwards).
Thanks for the ideas, and believe me I wish I could talk them into keys, but it just isn't in the cards. Hopefully someone can shove me in the right direction, or point me towards something I haven't figured out yet.
If they have to type a password anyway, why not let ssh do the password work? You can do as I did above without the keys, and ssh will ask for a password once to do all the commands in the here-document...
For work with multiple servers, I have a key with a password on it, which I cache with ssh-agent. It asks me once for my key password, on login, and I can use it until I log out to access any servers that were given that key. It's still password protected, but with one password entry, not 9,000.
The ultimate argument is this: If they hate the idea of keys, they'd be absolutely livid to know you were using a third-party brute-force hacking utility to sledgehammer in passwords in an insecure manner instead.
No no. I do not have the password stored on the script. They enter thier sign-in/password in the beginning of the script. And it is pulled into a variable while the script is running. As far as I know the variable isn't saved within the text of the script, it is cleared once the script exits and the session closes (I could be incorrect, cause I haven't been doing this too long).
I just need an alternate way, I am not authorized to use keys.
EDIT: Oh you must have snipe edited, your post said something a minute ago.
Sorry, I'm known to do that sometimes.
Hah, no problem. I tried it without the expect, just basic command line and it gets to the point of asking username and PW, then when entered just sits there. The script doesn't continue on if I remember correctly. Thats why I had to dig down in the depths for expect/send.
Perhaps I am misunderstanding your post though. Please clarify a bit if possible
Without seeing exactly what you did, word for word, letter for letter, keystroke for keystroke, I can't tell you why it didn't work. In principle there's nothing wrong with it.
There's potential pitfalls like your here-document never ending because you didn't put EOF at the beginning of a line, variables expanding sooner than you expected(and vanishing, if they're only set on the remote host rather than locally) and so forth...
Wow. I actually figured out my issue. It wasn't expecting the correct prompt, and each expect was actually timing out. Changed one symbol to another symbol and now everything runs ace. Thanks for trying though Corona