Safely remembering ssh credentials in bash script

Imagine I have a bash script that executes commands on a remote machine via ssh:

# Do something here
ssh otheruser@host command1
# Do something else
ssh otheruser@host command2
# Do most local tasks

This script prompts me to enter credentials for otheruser@host multiple times. Is there a safe, easy, and accepted way to cache these credentials for the lifetime of the script but guarantee that they are lost after the script ends (either normally or when an error occurs)? Maybe a solution will use ssh-agent?

I am looking for something like this:

special_credential_saving_command_here # This will prompt for credentials
ssh otheruser@host command1 # This will not prompt now
ssh otheruser@host command2 # This will not prompt either

My motivation here is to avoid entering the credentials multiple times in the same script while not running the risk of those credentials persisting after the script has terminated. Not only is entering the credentials cumbersome, it also requires I wait around for the script to finish so that I can enter the credentials rather than leave it to run on its own (it’s a long running script).

Solution:

Use a control socket to share an authenticated connection among multiple processes:

ssh -fNM -S ~/.ssh/sock otheruser@host  # Will prompt for password, then exit
...
ssh -S ~/.ssh/sock otheruser@host command1
ssh -S ~/.ssh/sock otheruser@host command2
...
ssh -S ~/.ssh/sock -O exit otheruser@host  # Close the master connection

See man ssh_config, under the ControlPath option, for information on how to create a unique path for the control socket.

Advertisements

bash list postgresql databases over ssh connection

I am doing some work on a remote Postgresql database.

When I log into the server this command works on bash:
$ psql -c “\l”

Remote login over ssh is possible using:

ssh user@server -C "cd /tmp && su postgres -c psql"

But why doesn’t it work from this command?

ssh user@server -C " cd /tmp && su postgres -c psql -c '\l' "
→   bash: l: command not found

This is working, also “psql -l” but I don’t understand why I have to use backslash 3 times here?

ssh user@server -C " cd /tmp && su postgres -c 'psql -c \\\l' "

Solution:

Use several levels of quoting:

ssh user@server -C "cd /tmp && su postgres -c 'psql -c \"\\l\"'"

Enable pem key based ssh linux

On the remote machine (machine to be sshed) execute:

ssh-keygen -t rsa
Press <Enter> key twice. One for public/private key file path and other for passphrase.

If required you can enter the passphrase.

By default, two keys will be created as follows:
$HOME/.ssh/id_rsa (private) and $HOME/.ssh/id_rsa.pub (public)

Create a pem key with the following command:
openssl rsa -in ~/.ssh/id_rsa -outform pem > id_rsa.pem

Edit the /etc/ssh/sshd_config file change as the following:

RSAAuthentication yes

PubkeyAuthentication yes

then restart ssh service : service sshd restart

cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

Copy the pem file to the machine from where you want to ssh the remote machine.
chmod 400 id_rsa.pem

Then ssh with:
ssh -i id_rsa.pem <remote m/c IP>

sudo: sorry, you must have a tty to run sudo

Replace Defaults requiretty by Defaults !requiretty in your /etc/sudoers. This will impact your global sudo configuration.

How to fix ‘sudo: no tty present and no askpass program specified’ error?

  1. Use NOPASSWD line for all commands, I mean:
    jenkins ALL=(ALL) NOPASSWD: ALL
    
  2. Put the line after all other lines in the sudoers file.

No activity on server with logging every 5 seconds

Recently I have notices that log files on my server grow faster than I was expecting. After a quick look I have realized that it is wtmp what aggressively is taking my disk space. Using utmpdump command (see below) I found out that every 5 seconds new 3 or 4 logs are recorded.

# utmpdump /var/log/wtmp | tail -n 25
Utmp dump of /var/log/wtmp
[6] [00886] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:08 2018 MSK]
[8] [00885] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:13 2018 MSK]
[6] [00889] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:13 2018 MSK]
[8] [00886] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:13 2018 MSK]
[6] [00890] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:13 2018 MSK]
[8] [00889] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:18 2018 MSK]
[6] [00897] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:18 2018 MSK]
[8] [00890] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:18 2018 MSK]
[6] [00898] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:18 2018 MSK]
[8] [00897] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:23 2018 MSK]
[6] [00899] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:23 2018 MSK]
[8] [00898] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:23 2018 MSK]
[6] [00900] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:23 2018 MSK]
[8] [00899] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:28 2018 MSK]
[6] [00901] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:28 2018 MSK]
[8] [00900] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:28 2018 MSK]
[6] [00902] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:28 2018 MSK]
[8] [00901] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:33 2018 MSK]
[6] [00906] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:33 2018 MSK]
[8] [00902] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:33 2018 MSK]
[6] [00907] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:33 2018 MSK]
[8] [00906] [1   ] [        ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:38 2018 MSK]
[6] [00910] [1   ] [LOGIN   ] [tty1        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:38 2018 MSK]
[8] [00907] [2   ] [        ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:38 2018 MSK]
[6] [00911] [2   ] [LOGIN   ] [tty2        ] [                    ] [0.0.0.0        ] [Wed Feb 07 17:26:38 2018 MSK]

There is no load on the server:

# w
 17:34:03 up 17 min,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/2    cpe-75-177-130-5 17:24    0.00s  0.02s  0.00s w

And no strange processes ruining:

# top
top - 17:35:08 up 18 min,  1 user,  load average: 0.00, 0.00, 0.00
Tasks:  28 total,   1 running,  27 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.3%us,  0.0%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2097152k total,    47060k used,  2050092k free,        0k buffers
Swap:        0k total,        0k used,        0k free,    28024k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 1141 root      20   0 11452 3536 2724 S  1.3  0.2   0:00.11 sshd
    1 root      20   0  2844 1440 1228 S  0.0  0.1   0:00.27 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd/9506
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper/9506
   72 root      16  -4  2560  600  364 S  0.0  0.0   0:00.00 udevd
   98 root      18  -2  2556  604  364 S  0.0  0.0   0:00.00 udevd
   99 root      18  -2  2556  604  364 S  0.0  0.0   0:00.00 udevd
  458 root      20   0  9400 1008  520 S  0.0  0.0   0:00.02 sshd
  469 root      20   0  3144  940  760 S  0.0  0.0   0:00.00 xinetd
  483 root      20   0  6224  576  264 S  0.0  0.0   0:00.00 vsftpd
  494 root      20   0  8704  864  468 S  0.0  0.0   0:00.00 saslauthd
  496 root      20   0  8704  552  156 S  0.0  0.0   0:00.00 saslauthd
  514 root      20   0 12352 1820  708 S  0.0  0.1   0:00.01 sendmail
  521 smmsp     20   0 12152 1624  644 S  0.0  0.1   0:00.00 sendmail
  533 root      20   0 25096 6956 3932 S  0.0  0.3   0:00.03 httpd
  543 root      20   0  1964  496  436 S  0.0  0.0   0:00.00 mingetty
  544 root      20   0  1964  488  436 S  0.0  0.0   0:00.00 mingetty
  552 root      20   0  1964  492  436 S  0.0  0.0   0:00.00 mingetty
  554 root      20   0  1964  488  436 S  0.0  0.0   0:00.00 mingetty
  556 root      20   0  1964  492  436 S  0.0  0.0   0:00.00 mingetty
  558 root      20   0  1964  492  436 S  0.0  0.0   0:00.00 mingetty
  559 apache    20   0 25096 3676  628 S  0.0  0.2   0:00.00 httpd
  831 root      20   0 12572 3652 2908 S  0.0  0.2   0:00.06 sshd
  833 root      20   0  6372 1712 1472 S  0.0  0.1   0:00.02 bash
 1136 root      20   0  2548 1076  892 R  0.0  0.1   0:00.00 top
 1142 sshd      20   0 10744 1452  876 S  0.0  0.1   0:00.01 sshd
 1145 root      20   0  1960  592  532 S  0.0  0.0   0:00.00 mingetty
 1146 root      20   0  1960  596  532 S  0.0  0.0   0:00.00 mingetty

What is behind these log records and why such tasks are recorded every 5 seconds? Is there a way to stop record those “dummy” logs and have only real login logs recorded?

Solution:

Record all processes running during 50 seconds

for i in {1..10} ; do ps -efH | tee -a ~/tmp/pids-5.txt; sleep 5; done

Then dump wtmp contents and check second column values against pids-5.txt. It should tell you which user and command the PID belongs to.
You could then do something to avoid those process running.

Can't kill process started by another ssh session in bash script

I’m writing a bash script where I need to login in a remote machine via ssh, start a process, end the ssh session, do some other things, and then login again via ssh to kill the process. But the process doesn’t get killed. I have tried a lot of ways.
Here is the part of the script that won’t work:

ssh localadmin@10.101.30.61 &>/dev/null << EOF
tshark -i ens160 -w /home/localadmin/dns_traffic_61.pcap &>/dev/null &
EOF


ssh localadmin@10.101.30.61 &>/dev/null << EOF
kill $(pidof tshark)
EOF

I have also tried putting the tshark command in a script so I would kill the script like this:

ssh localadmin@10.101.30.61 &>/dev/null << EOF
sh tshark.sh &>/dev/null &
EOF

ssh localadmin@10.101.30.61 &>/dev/null << EOF
pid=$(ps -ef | grep tshark.sh | grep -v grep | awk '{print $2}')
kill $pid  
EOF

and this:

ps -ef | grep tshark.sh | grep -v grep | awk '{print $2}'|xargs kill

Nothing seems to work.

Note: When I connect via ssh manually I can kill the process, only the bash script can’t.

Solution:

use single quotes around end marker so that expansion doesn’t occur in current shell but in remote

ssh localadmin@10.101.30.61 &>/dev/null << 'EOF'
kill $(pidof tshark)
EOF

compare

cat << EOF
$$
EOF

and

cat << 'EOF'
$$
EOF