If you like DNray Forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...

 

Overcoming Key Generation Challenges with Custom Scripts

Started by UMMark, Oct 23, 2024, 12:52 AM

Previous topic - Next topic

UMMarkTopic starter

I'm not very familiar with *nix systems or bash scripting, so I hope you won't be upset with me. There's this software called Tinc, specifically version 1.1. I need to create keys using a script that has a specific key length and designated paths. The issue arises when I execute the script; it effectively hijacks the command line interface, and I end up interacting with it like it's a shell (similar to netsh on Windows). When I try to send data using echo or printf, Tinc interprets it as an empty input and defaults to its standard paths.
I even attempted using pipes, but there was zero response. I've been troubleshooting this for two days with no success... I could really use some assistance. Thanks a lot!

Just to clarify, it's Tinc version 1.1, not 1.0. The key generation process has been completely overhauled in this version; in 1.0, it was straightforward with just human-readable keys.
  •  


ajivets

To overcome this, you can try using the expect command, which allows you to script interactions with other programs in a more flexible way. You can use expect to send the necessary input to the Tinc script, such as the key length and paths, and then capture the output.

Another approach would be to modify the Tinc script itself to accept input through command-line arguments or a configuration file, rather than relying on interactive input. This would allow you to run the script in a non-interactive manner and avoid the hijacking of your command line interface.

If you want to automate key creation, you should leverage the command-line options instead of relying on the interactive shell. Use tincd -n <network> -K <key-length> to generate keys without entering the interactive mode. This method is cleaner and avoids the headaches of dealing with Tinc's shell-like behavior.
  •  

SapSakIntitty

When executing this utility, are you aware of the underlying environment and shell you're operating within? Specifically, if you're on a Windows platform, are you invoking it via the cmd.exe interface or an alternative shell?

To troubleshoot, you may want to experiment with a workaround similar to this:

#!/bin/bash

# Define the netname and key size
NETNAME="my_netname"
KEY_SIZE=4096

# Create a temporary file to store the parameters
PARAMS_FILE=$(mktemp)

# Write the parameters to the file
echo "parameter_which_will_ask_1" > "$PARAMS_FILE"
echo "parameter_which_will_ask_2" >> "$PARAMS_FILE"
echo "parameter_which_will_ask_1" >> "$PARAMS_FILE"

# Execute tinc with the custom configuration file
tinc -c "$PARAMS_FILE" -n "$NETNAME" generate-keys "$KEY_SIZE"

# Clean up the temporary file
rm "$PARAMS_FILE"

Upon reviewing the dоcumentation, I noticed that tinc offers an option to parse configuration parameters from a custom file: https://www.tinc-vpn.org/dоcumentation.html

-c, --config=path

Read configuration options from the directory path. The default is /etc/tinc/netname/. You can craft a bespoke configuration file containing the necessary parameters and point to it, allowing tinc to read from it.

A crucial consideration is the console and shell you're using to execute the utility, as the behavior may differ significantly between Windows, Unix-like systems (e.g., Linux, macOS), and other environments. For instance, Windows employs a CRLF (Carriage Return + Line Feed, 0x0D + 0x0A) line termination, whereas Unix-like systems use a single LF (Line Feed, 0x0A) character. These subtle discrepancies can lead to significant issues and time losses if not properly addressed.
  •  

znickollo19

It appears that the software neglects to verify the shell's interactivity, instead opting to inspect the buffer for any residual content. If it detects something, it disregards it outright, eschewing any further inquiry. This behavior seems to be an intentional design choice, possibly intended to circumvent potential workarounds.

While it may be feasible to bypass this restriction, doing so would necessitate a considerable amount of technical acrobatics. In my opinion, the most expedient solution involves reconfiguring the default paths to utilize symbolic links, which can then be modified at will within the script. Only after this tweak can the program be executed as desired.
  •  


If you like DNray forum, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...