-1

I have this basic script file.sh that connects to a server

name=username
routerip=172.21.200.37

echo "$name""@""$routerip"
ssh "$name""@""$routerip"

sample output:

$ ./file.sh
username@172.21.200.37
username@172.21.200.37's password:

What I am wondering is how to best handle the password that is requested in my script. Should I use expect? Or is there another way. Also if the password is in the script should it be encrypted for security?

And maybe a silly question but, is there a way to connect to the server with haveing a username?

HattrickNZ
  • 4,373
  • 15
  • 54
  • 98

2 Answers2

0

If you care about security, you definitely don't want to embed the password in the script. And you can't really "encrypt" the password, either, because the script would have to know how to decrypt it, and anyone reading the script would see how you did it (and what the decryption key was, etc.).

If you have a script running on machine A that is authorized to log in to machine B, the way I've always done it is to set up a private ssh key on machine A, and put the public key in the user's authorized_keys file on machine B.

(In answer to your last question, no, there's no way to do this sort of login without a username.)

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
0

I agree with @Steve Summit that, if machine B has public key of machine A then just by giving username you can login. You don't need to give password.

Use the below simple script to solve your problem

USERNAME=myUsername
GRID=$1
SERVER=$2

echo "=================== Connecting ==================="
if [ ${GRID} == 'dev' ] && [ ${SERVER} == 'uk' ]
then
        ssh -l ${USERNAME} "dev-uk.xyz.com"

elif [ ${GRID} == 'dev' ] && [ ${SERVER} == 'us' ]
then
        ssh -l ${USERNAME} "dev-us.xyz.com"

else
ssh -l ${USERNAME} ${GRID}"-"${SERVER}".xyz.com"
fi

So, while connecting you just need to run

./file.sh dev uk

or

./file.sh qa jer
  • 1
    Note in [How to Answer](https://stackoverflow.com/help/how-to-answer) the section "Answer Well-Asked Questions", and the bullet point therein regarding questions which "...have been asked and answered many times before". – Charles Duffy Apr 17 '19 at 13:08
  • Also, your script is quite buggy -- try running it through http://shellcheck.net/. `${foo}` is just as prone to string-splitting and glob expansion as `$foo` is; you need to make it `"$foo"` to suppress those behaviors. And you don't need to quote literals that don't contain any whitespace or other shell-syntax-relevant sensitive characters at all, but you *do* need to quote expansions. And `==` isn't guaranteed to work in `[ ]`, being a ksh/bash extension; for compatibility with all POSIX-compliant shells, use `=` instead. – Charles Duffy Apr 17 '19 at 13:14
  • All-caps variable names are used for names meaningful to the shell itself and to POSIX-specified utilities, whereas lowercase names are guaranteed not to conflict -- see http://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap08.html, keeping in mind that setting a shell variable will overwrite any like-named environment variable: *The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.* – Charles Duffy Apr 17 '19 at 13:18