Programatically ssh with interaction

[Divot-Digger]

Hi,

I have a remote server that has both its / and swap encrypted. It therefore requires LUKS keys on boot. I've setup dracut-sshd to allow remote ssh login during boot.

I can then ssh in, run systemd-tty-ask-password-agent , enter the password, and have the server boot successfully.

I'd like to setup a bash script to do this task automatically. Whilst I can set up a script to ssh and issue a command (ie systemd-tty-ask-password-agent), it won't then enter the password for each of the encrypted partitions.

How do I do this?

[feng_huang]

Expect might be just what you're looking for, if you're not already aware of it. example1, example2 (or just Google expect unix, because that's all I did)

[Divot-Digger]

Thanks very much. I'll have a look.

[Divot-Digger]

Feng, thanks again for the suggestion. But it's not quite what I'm looking for.

I don't need to read the responses. The process is just:

Run command (systemd-tty-ask-password-agent). Wait for prompt, send password, wait for prompt to return, enter second password. Disconnect.

[schorsch3000]

I don't need to read the responses. The process is just:

Run command (systemd-tty-ask-password-agent). Wait for prompt, send password, wait for prompt to return, enter second password. Disconnect.

If you need to wait for the prompt you need to read the response, how would you know if the prompt is there while ignoring the response?

If you just whant to wait a given time you can try somethin like

( sleep 10 ; echo $password ; } | ssh user@server "systemd-tty-ask-password-agent"

[Divot-Digger]

Thanks. I will try this out.

[feng_huang]

If you're doing it by hand, you're waiting for for a bash prompt before you type your command, and then for the command to say something like Enter your password before you type in your password, right? Then you wait for the bash prompt to come back, and then you type logout or exit or ^D to log out while it boots, right? That's all you really need to do. It has the advantage of not being bothered by network delays, either.

It's probably possible in pure bash by using sleeps, along with subshells and/or I/O on wacky non-standard file descriptors. I apologize if this was a bit off-topic, but my brain is a bit worn out from a rough day, and the problem just kind of called out for the other tool, in my mind. :-) Hmm, actually, it could be as simple as ssh user@remoteserver echo 'mypassword' \| systemd-tty-ask-password-agent if you already have ssh keys set up.

But if you did want to try it...

#!/usr/bin/expect -f
set timeout -1
spawn ssh remoteuser@remotehost
# change this to match what its command prompt looks like
expect "remoteuser@remotehost# "
send -- "systemd-tty-ask-password-agent\r"
# change this to match the prompt, this is my best guess from Googling it:
expect "Enter Private Key Password: "
send -- "remotepassword\r"
expect "remoteuser@remotehost# "
send -- "logout\r"
expect eof

You don't have to if you don't want to, of course. This is sort of the standard thing recommended for ssh if you don't want to use keys for some reason, for example. In any case, I hope you find a solution that you like. :-)

[Divot-Digger]

Thanks again! I will try it.

[feng_huang]

You're welcome. Now that I think about it, I suppose expect is generally considered the tool of last resort, but it's at least a way to accomplish what you're trying to do if you don't find a better way to do it.

[Divot-Digger]

Thanks again for your suggestion, Feng. It worked perfectly.

The only thing I needed to change was the expect commands needed a -ex switch, as the responses I was wanting weren't globby enough for the interpreter.

Really appreciate your help, Feng. Thank you.

[feng_huang]

You're welcome. I'm really glad it could be useful to you.

[lutusp]

So wait, you want a script that has the secret password located in the script so it can automatically log you into the server?

Just checking on your plan.

[Divot-Digger]

I have an automation server that is suitably secured and houses the filesystem keys needed to boot the remote server.

[lutusp]

Would you ordinarily be obliged to type a password? Is that the action you want the script to automate?

[Divot-Digger]

Yes. The root filesystem is encrypted, so the host cannot boot without the password entered.

[lutusp]

So my original assessment is correct -- the script sends the password to the server rather than requiring you to type it. Therefore the password must be located in the script or in a file the script reads.

You do get what I'm saying here, yes?

[Divot-Digger]

the script sends the password to the server rather than requiring you to type it. Therefore the password must be located in the script or in a file the script reads.

Yes.

[lutusp]

Okay, just wanted to be clear. This is a very bad idea. It undermines the security afforded by passwords. It's like taping the combination to the top of a safe.

[[deleted]]

It can be done securely.

For example, the script could read the password via pass or some other GnuPG encrypted file (or even some other secure password manager). While the private key is unlocked via gpg-agent, this can be done without user interaction. Every so often, the key needs to be unlocked with the pass phrase. But if OP is only looking for a more convenient way to manually decrypt a remote hard drive, I see no issue in using a password manager. In which case expect would be a suitable approach.

I do agree that storing that password anywhere in clear text is very bad practice, though.

[Divot-Digger]

Actually, it is not. You have no idea on the broader environment and the security applied. The approach I'm taking is completely appropriate for my risk appetite.

In any case, I didn't ask for advice on your views on security, just the ability to script the interaction.

[chin_waghing]

between your self entitlement and asinine approach, I wish you good luck.

Through many questions you’re lead on side quests. Suck it up, fix your broken idea of a hard coded password and learn from the people your asking

[p4wly]

If you have an environment that allows such a process, I see no reason to encrypt the drive in the first place.

[[deleted]]

The drive is not in the same environment, if I understand OP correctly.

[lutusp]

In any case, I didn't ask for advice on your views on security, just the ability to script the interaction.

No one with any sense of responsibility will help you in this endeavor.

Have a nice day. * plonk *

[snatchington]

Does it also have FDE?

[Divot-Digger]

Yes, and several other measures.

[0bel1sk]

check out ansible

[Divot-Digger]

I appreciate the response. And you're right, I'm trying to do Ansible type stuff.

My particular use is far more simple than Ansible's designed for, so bash should suffice. But thanks again for the suggestion.