1. Secure communication between server S and Master M
  2. Server S executes script downloaded from Master M (securely)


  1. Small footprint - use existing software (base install of a unixsystem)

  2. Mostly automated

(Possible) "Protocol":


  • Server S and Master M share a common secret SM_KEY (one time password), which is exchanged over a secure channel before the protocol starts. This can be telephone, encrypted email between or any other channel between the two systemowners
  • Master has Keypair (K_M, K_M_pub) for signing (OpenSSL)


  1. Server S generates a OpenSSH-Keypair

    (K_S, K_S_pub)

  2. Server S sends K_pub to Master M via HTTPS-GET/POST, as well MAC-secured checksum :

    S -> K_S_pub, MAC(K_S_pub)_SM_KEY -> M

  3. Master M verifies MAC with SM_KEY and safes K_S_pub

  4. Master M sends his public key and MAC-secured checksum (server "downloads" it via HTTPS):

    M -> K_M_pub, MAC(K_M_pub)_SM_KEY -> S

Operation Phase

  1. Server downloads skripts via HTTPs to execute which are signed by private Key of the master (K_M) and verify it with K_M_pub
  2. Server uploads results to master via SFTP by authenticating with private key K_S (Master can verify the attempt with K_S_pub)

Used tools

  • OpenSSL for sign / verify (RSA-Keys)
  • OpenSSH for SFTP (pubkey-Authentication)
  • wget for HTTPS-Requests (Communication from Server to master)

Possible Attacks

  • MITM Install: Because of the MAC(K_S_pub)_SM_Key the Master can recognize it and abort further communication; Server can recognize forged answer by verifying MAC as well
  • MITM Operation: Only signed scripts will be executed, uploading is secured by SFTP

Do I miss any anything?

closed as unclear what you're asking by schroeder, Xander, Eric G, Stephane, Rory Alsop Apr 13 '15 at 12:04

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • what speaks against using a PSK-ciphersuite for TLS? what speaks against giving the server a server/"client" TLS-certificate for authentication?(better than PSK) As soon as HTTPS connection is safe, any tampering on transmitted data will be noticed by TLS impl. – SEJPM Apr 12 '15 at 16:37
  • There is no CA which can hand out client certificates. Also there is no "built in" tool on all platforms (as far as I know) for uploading data over https / webdav - wget / curl are there for requests. HTTPs safes the transport from Master to Server, but the signing of the scripts should safe the Server from executing malicious scripts (which were tampered on the master). – Markus Apr 12 '15 at 18:16

The operation phase is fine.

HTTPS should protect against MITM attacks in the operational phase.
Signing of the data is fully acceptable in the operational phase.

The installation phase is fine, although I suspect that you meant HTTP instead of HTTPS. This will work and the MAC's will protect from tampering.
What I'm now proposing is a "could be".

You could use OpenSSL instead of OpenSSH for the server S.
You could formulate a CSR for a S/MIME and TLS client certificate and let it be signed by the master server M (acting as a CA). Both server could then afterwards connect via mutually authenticated HTTPS and you could use the S/MIME cert-part to authenticate output, as the master would be the only one that would need to trust himself.

  • So for mutal authentication of the downloads it would be fine - I will clarify it. For mutal authentication of the upload I will use OpenSSH / SFTP with strict checking of the hostkey of the master. Then it should be fine, shouldn't it? – Markus Apr 13 '15 at 13:53
  • if OpenSSH/SFTP is easier to use for you than HTTPS is that shouldn't be a problem, as there are no security issues with OpenSSH (SFTP is based on SSH). – SEJPM Apr 13 '15 at 16:53

Not the answer you're looking for? Browse other questions tagged or ask your own question.