knownhosts for Ant scp and sshexec tasks - ant

My question is similar to the one asked here:
Ant scp task failure
BUILD FAILED com.jcraft.jsch.JSchException: reject HostKey: ....
My question is why are the keys not found in my knownhosts file?
No matter what kind of known_hosts file I have, the host key is rejected. Connecting via ssh works perfectly fine, and adds the relevant entries, but maybe jsch is unable to read known_hosts files generated by OpenSSH?
The Ant docs mention that the knownhosts file needs to be in SSH2 format, not SSH1. Ironically, the SSH2 format known_hosts file from OpenSSH is supposed to be ~/.ssh/known_hosts2, but the default value for knownhosts is ~/.ssh/known_hosts.
The known hosts files created by SSH2 are in ~/.ssh2/knownhosts/, so it's probably safe to count that out for the expected format. So far I've been unable to get OpenSSH to create a known_hosts2 file, and the man pages aren't much help there either. So what do the docs actually mean that the file needs to be in SSH2 format?
I've tried dsa and rsa keys, and neither work (both work with OpenSSH).
I've searched for two days and the only answers I've found are 'set trust="true'. Yes, that gets the task working, but not without turning a blind eye to security.

Here's a format I found that works with more recent versions of jch:
[xx.xx.xx.xx]:22 ssh-rsa .......
In older versions it was like:
xx.xx.xx.xx ssh-rsa ......
i.e. no square brackets and no port number. (Not sure if the port number is necessary if you're using port 22, but I tested it with a server with a non-default port assigned for SSH. And, in case it's not obvious, xx.xx.xx.xx should be the IP address of the server, or hostname or whatever.)
I found this format by getting the JCraft/jsch library to generate the known_hosts file for me. If you visit www.jcraft.com you can download a zip of the jsch source code, and some examples. Either build the source to make a jar, or download the ready-made jar as well. I unzipped the zip download and then plopped the jar file in that same directory.
There's an examples folder containing KnownHosts.java. You need to compile that file and then run it - it will ask you for your known_hosts file (just create an empty file in the default location first (~/.ssh/known_hosts) and select that. It will then ask you for details to connect to a server... Enter those, for example sshusername#xx.xx.xx.xx, and the program will try to connect and then fill the known_hosts file for you.
For convenience for blundering Windows users like me who can never remember how to do stuff from the command line, here's what you need to compile and run that KnownHosts.java file:
First, navigate to the directory (having unzipped it and put the jar file inside, as I described above).
Then run:
javac -cp jsch-0.1.49.jar examples/KnownHosts.java
to compile KnownHosts.java. And then:
java -cp "examples;jsch-0.1.49.jar" KnownHosts
to run it. Follow through the instructions above and you should have a working known_hosts file.
One final note: the KnownHosts program assumes a port of 22. I edited it to allow me to enter something like sshusername#xx.xx.xx.xx:8888 so I could specify a server with a custom port and have it work as described above. In the source of KnownHosts.java I looked for a line like:
Session session=jsch.getSession(user, host, 22);
and replaced it with:
int port = 22;
final int colonIndex = host.indexOf(':');
if (colonIndex > -1) {
final String[] split = host.split(":");
host = split[0];
port = Integer.parseInt(split[1]);
}
Session session=jsch.getSession(user, host, port);
and then compiled and ran as above.

The sshexec ant task is looking for the file 'known_hosts' by default to ${user.home}/.ssh/known_hosts
Verify the value of 'user.home' system property. Probably it points to unsuspected place.
Or provide the 'knownhosts' value explicitly in the ant task's property.

There are two parameters you might be interested in:
trust: If set to true will trust unknown hosts. The default is set to false.
knownhosts: Set to the location of your known hosts file.
The first will allow you to set the tasks to not check whether or not it's a known host. The second will allow you to specify the file that contains the known hosts. This way, you could specify it as ${user.home}/.ssh/known_hosts2and override the default.
By the way, a good way to do this is to use properties for these values, and then use a property file to override those properties:
[...]
<property name="build.properties" value="build.properties"/>
<property file="${build.properties}"/>
<!-- Can be overridden via 'build.properies' file -->
<property name="knownhosts.file" value="${user.home}/.ssh/knownhosts"/>
<property name="remote.host" value="foo-system"/>
[...]
<scp file="${copy.this.file}"
todir="${user}#{host}:${remote.dir}"
knownhosts="${knownhosts.file}"/>
[...]

Related

How can I tell what options are in use on a running Mosquitto Service

How can I tell if the settings files associated with a Mosquitto instance, have been properly applied?
I want to add a configuration file to the conf.d folder to override some settings in the default file, but I do not know how to check they have been applied correctly once the Broker is running.
i.e. change persistence to false (without editing the standard file).
Test it.
You can run mosquitto with verbose output enabled, which will generally give you feedback on what options were set, but don't just believe that.
To do that, stop running Mosquitto as a service (how you do this depends on you setup) and manually run it from the shell with the -v option. Be sure to point it at the correct configuration file with the -c option.
That's not enough to be sure that it's actually working properly. To do that you need to test it.
Options have consequences or we wouldn't use them.
If you configure Mosquitto to listen on a specific port, test it by trying to connect to that port.
If you configure Mosquitto to require secure connections on a port, test it by trying to connect to the port unsecured (this shouldn't work) and secured (this should work).
You should be able to devise relatively simple tests for any options you can set in the configuration file. If you care if it's actually working, don't just take it on faith; test it.
For extra credit you can bundle the tests up into a script so that you can run an entire test suite easily in the future and test your Mosquitto installation anytime you make changes to it.
Having duplicate configuration options with different values is a REALLY bad idea.
The behaviour of mosquitto is not defined in this case, which value should be honoured, the first found, the last? When using the conf.d directory, what order will the files be loaded in?
Also will you always remember that you have changed the value in a conf.d file in the future when you go looking?
If you want to change one of the defaults in the /etc/mosquitto/mosquitto.conf file then edit that file. (Any sensible package management system will notice the file has been changed and ask what to do at the point of upgrade)
The conf.d/ directory is intended for adding extra listeners.
Also be aware that there really isn't a default configuration file, you must always specify a configuration file with the -c command line option. The file at /etc/mosquitto/mosquitto.conf just happens to be the config file that is passed when mosquitto is started as a service when installed using most Linux package managers. (The default Fedora install doesn't even setup the /etc/mosquitto/conf.d directory)

Why isn't telegraf reading environmental variables?

My goal is to put my telegraf config into source control. To do so, I have a repo in my user's home directory with the appropriate config file which has already been tested and proven working.
I have added the path to the new config file in the "default" environment variables file:
/etc/default/telegraf
like this:
TELEGRAF_CONFIG_PATH="/home/ubuntu/some_repo/telegraf.conf"
... as well as other required variables such as passwords.
However, when I attempt to run
telegraf --test
It says No config file specified, and could not find one in $TELEGRAF_CONFIG_PATH etc.
Further, if I force it by
telegraf --test --config /home/ubuntu/some_repo/telegraf.conf
Then the process fails because it is missing the other required variables.
Questions:
What am I doing wrong?
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
What am I doing wrong?
See what user:group owns /etc/default/telegraf. This file is better used when running telegraf as a service via systemd. Additionally, if you run env do you see the TELEGRAF_CONFIG_PATH variable? What about your other variables? If not, then you probably need to source the file first.
Is there not also a way of specifying a config directory too (I would like to break my file down into separate input files)?
Yes! Take a look at all the options of telegraf with telegraf --help and you will find:
--config-directory <directory> directory containing additional *.conf files
Perhaps as an alternative to all of this... is there not a way of specifying additional configuration files to be included from within the default /etc/telegraf/telegraf.conf file? (I've been unable to find any mention of this in documentation).
That is not the method I would suggest going down. Check out the config directory option above I mentioned.
Ok, after a LOT of trial and error, I figured everything out. For those facing similar issues, here is your shortcut to the answer:
Firstly, remember that when adding variables to the /etc/default/telegraf file, it must effectively be reloaded. So for example using ubuntu systemctl, that requires a restart.
You can verify that the variables have been loaded successfully using this:
$ sudo strings /proc/<pid>/environ
where <pid> is the "Main PID" from the telegraf status output
Secondly, when testing (eg telegraf --test) then (this is the part that is not necessarily intuitive and isn't documented) you will have to ALSO load the same environmental variables into the current user (eg: SET var=value) such that running
$ env
shows the same results as the previous command.
Hint: This is a good method for loading the current env file directly rather than doing it manually.

Trouble Enabling SSL on Fuseki Server

I'm hoping some of you may be able to help me with setting up SSL on my fuseki server. I've been battling with it for a few days now and am running out of possible solutions!
OS: RHEL 8.5 (Ootpa)
Fuseki: Version 4.2.0
Currently running as system service with:
ExecStart=/home/fuseki/apache-jena-fuseki-4.2.0/fuseki-server -v -tdb2 -update -config=/home/fuseki/fuseki_data/config.ttl
This is the manual I've been working with- https://jena.apache.org/documentation/fuseki2/fuseki-data-access-control.html
The following are the provided arguments to add in the startup sequence of fuseki-server.
–https=SETUP [Name of file for certificate details.]
& –httpsPort=PORT [The port for https. Default: 3043]
The --https argument names a file in JSON which includes the name of
the certificate file and password for the certificate.
The issue is that no matter how I phrase the arguments the process returns "fuseki-server[9469]: Unknown argument: https" in the journalctl logs.
I have tried -https=dir, --https=dir, & -httpsConf=dir (where dir is the directory to my cert_details.json file).
Based on the docs https should have native support but when I check fuseki-server -help there is no mention of an https argument. I have created a .jks from my cert, have set the correct file permissions, and have allowed 3043.
I have also located the block of code in fuseki that resolves the keystore and passwd from the .json file (which led me to try using -httpsConf=)
private void setHttpsCert(String filename) {
try {
JsonObject httpsConf = JSON.read(filename);
Path path = Path.of(filename).toAbsolutePath();
String keystore = httpsConf.get("keystore").getAsString().value();
// Resolve relative to the https setup file.
this.httpsKeystore = path.getParent().resolve(keystore).toString();
this.httpsKeystorePasswd = httpsConf.get("passwd").getAsString().value();
Not sure what I'm missing here. For what it's worth I'm a chemist and I definitely don't know java all that well so it very well could be me being stupid. Any suggestions/knowledge would be greatly appreciated.
there are two ways to get HTTPS+Fuseki:
The document referred to is for the jar file here: https://repo1.maven.org/maven2/org/apache/jena/jena-fuseki-server/4.2.0/jena-fuseki-server-4.2.0.jar, not the jar in the apache-jena-fuseki download. (BTW It does not have the UI.)
The one in the apache-jena-fuseki can be use HTTPS by using a Jetty configuration using --jetty=jetty.xml (https://www.eclipse.org/jetty/documentation/current/jetty-xml-config.html) -- example: https://github.com/apache/jena/blob/main/jena-fuseki2/examples/fuseki-jetty-https.xml (which will need modifying).

jenkins not reading config file

I am trying to get Jenkins to use https I have created my JKS file and I have amended the /etc/default/jenkins file. I have set http_port=-1 and have changed the last line in the file to someting similar to :-
JENKINS_ARGS=” — httpPort=-1 — httpsPort=8443 — httpsKeyStore=/path/to/jenkins.jks — httpsKeyStorePassword=chosen_pass — httpsListenAddress=0.0.0.0"
replacing the path to jenkinks with the relevant path and password with correct password.
When I restart jenkins it just defaults to port 8080 on http. It seems to ignore the modifications to this field
Has anyone see this before. Am I editing the correct file?? I am on Ubuntu 18.

How to run Grails Wrapper (grailsw) behind a proxy?

I tried to run grailsw, but the wrapper cannot connect to download grails-2.2.1-download.zip (creates a 0 byte file instead).
I need to use a proxy server to connect to the internet, where do I configure proxy settings for the Grails Wrapper?
After running grails wrapper, your project directory has a new subdirectory called wrapper, with a file grails-wrapper.properties. You can configure your proxy settings in there, with the following properties:
systemProp.http.proxyHost=
systemProp.http.proxyPort=
systemProp.http.proxyUser=
systemProp.http.proxyPassword=
systemProp.http.nonProxyHosts=
I solved this problem for myself.
It is a two step process
1.a) Back up your JRE_HOME\lib\security folder. This is essential because the below steps might corrupt cacerts file under jre.
1.b) You need to install the ssl public key of Github.com to your local file system. To do that you have to use the InstallCert.java program( Link to InstallCert.java )
It is supposed to be run as java InstallCert github.com
and when it asks to enter cert number you need to enter 1
It will create a file with name "jssecacerts" in the current directory
1.c) But this program will not work because it does not know about how to authenticate with proxy. For this you need the code from SSLSocketClientWithTunneling page
Use the above two and create a program that tunnels through the proxy retrieves the ssl key and writes a file called jssecerts
2) Update your grails.bat with addtional options. Add these options to the %JAVA_EXE% command line. Paste them after %DEFAULT_JVM_OPTS%
-Dhttp.proxyHost=YourproxyURL -Dhttp.proxyPort=YourproxyPort -Dhttps.proxyHost=YourproxyURL -Dhttps.proxyPort=YourproxyPort -Dhttp.proxyUser=YourProxyUserID -Dhttp.proxyPassword=YourProxyPassword -Dhttps.proxyUser=YourProxyUserID -Dhttps.proxyPassword=YourProxyPassword -Djavax.net.ssl.trustStore=path-to-your-jssecacerts-created-in-step-1

Resources