NoMachine 3.5 Client Can't Connect to 4.0 Server? - centos6

I read that 3.5 client should be able to connect to 4.0 server.
However, when I tried to connect, I got this log:
NX> 203 NXSSH running with pid: 4468
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: x.y.z on port: 42228
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
NX> 204 Authentication failed.
Then, I looked at:
https://www.nomachine.com/DT12I00037#3.1
It seems like 4.0 needs some setup for the authentication part. With 3.5, installing the rpm is the only step.
Any idea?

The client 3.5.0 connects to a server by SSH protocol and NoMachine login (public key authentication), while NoMachine 4 (free) supports only connections by NX protocol.
To be able to connect with NX client 3.5.0, you need to install any of the NoMachine Terminal Server or Enterprise products v. 4 that supports SSH connections.
More about this is available here: https://www.nomachine.com/AR04H00561
Alternatively, install NoMachine client (version 4) on the computer you are connecting from and use the NX protocol to connect.

Related

BouncyCastle ALPN broken when running with JDK 11 code compiled with JDK 8

I setup my jdk provider by
Security.addProvider(new BouncyCastleFipsProvider()).
Set it in the Grpc client by:
SslContextBuilder sslContextBuilder = SslContextBuilder.forClient()
.sslProvider(SslProvider.JDK)
.applicationProtocolConfig(new ApplicationProtocolConfig(
ApplicationProtocolConfig.Protocol.ALPN,
ApplicationProtocolConfig.SelectorFailureBehavior.NO_ADVERTISE,
ApplicationProtocolConfig.SelectedListenerFailureBehavior.ACCEPT,
Collections.singletonList("h2")));
When trying to establish the connection, After successful ssl handshake I get:
UNAVAILABLE: Failed ALPN negotiation: Unable to find compatible protocol
Channel Pipeline: [SslHandler#0, ProtocolNegotiators$ClientTlsHandler#0, WriteBufferingAndExceptionHandler#0, DefaultChannelPipeline$TailContext#0]
I'm using grpc 1.44 version + bc-fips.jar 1.0.2 version.
Running my app by java 11.0.15 compiled by jdk1.8.0_291.jdk.
It looks like BouncyCastleFipsProvider, by its SSLParamertesUtil class, somehow remove the "h2" from the suggested application protocols list.
increasing grpc version to 1.46 didn't help.
Any suggestions please?
Thanks.

Access impossible to newly setup EJBCA PKI

I have just finished installing ejbca community edition on top of wildfly.
The EJBCA server is a VM in the azure cloud.
everything went fine during build : Build successful for every 3 steps of deployment.
- ant deployear
- ant runinstall
- ant deploy-keystore)
Versions :
Wildfly 18.0
EJBCA 7.4.3.2
Ant 1.10.10
Mysql Ver 15.1 Distrib 10.3.27-MariaDB
JDBC connector : mariadb 2.7.3
Debian 10 buster
However i am unable to reach the destination
https://<public ip address>:8443/ejbca/
Error message :
The connection has timed out
The server at <my public ip #> is taking too long to respond.
So, started checking the different ports open :
**remote** nmap scan from my local vm to the remote EJBCA VM :
nmap -Pn8080,22,8442,8443,9990,3306 52.188.59.103
Host is up (0.037s latency).
Not shown: 995 filtered ports
PORT STATE SERVICE
21/tcp open ftp
80/tcp open http
443/tcp open https
554/tcp open rtsp
1723/tcp open pptp
Nmap done: 1 IP address (1 host up) scanned in 5.62 seconds
On the EJBCA VM a local port scan shows that port 8443 and 8080 are open :
rDNS record for 127.0.0.1: localhost
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
3306/tcp open mysql
8080/tcp open http-proxy
8443/tcp open https-alt
Azure connectivity tests from my ip to EJBCA host is OK for every ports tested.
however, online Port check says ports 8443 and 8442 are closed
https://portchecker.co/
So i don't know which test to trust ?
I tried disabling both my local firewall and my proxy but it didn't make any difference.
I did a tcpdump on the EJBCA server whilst trying to access ejbca url : but nothing was displayed.
What am i missing here ?
What other tests can i perform?
EDIT :
serverlog: (errors and warnings )
web admin error:
2021-06-14 13:00:07,332 ERROR [org.jboss.as.jsf] (MSC service thread 1-2) WFLYJSF0002: Could not load JSF managed bean class: org.ejbca.ui.web.admin.peerconnector.PeerConnectorsMBean
2021-06-14 13:00:07,433 ERROR [org.jboss.as.jsf] (MSC service thread 1-2) WFLYJSF0002: Could not load JSF managed bean class: org.ejbca.ui.web.admin.peerconnector.PeerConnectorMBean
Deprecated lib:
2021-06-14 13:00:14,598 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-000146: BeforeBeanDiscovery.addAnnotatedType(AnnotatedType<?>) used for class com.sun.faces.flow.FlowDiscoveryCDIHelper is deprecated from CDI 1.1!
Severe errors :
2021-06-14 13:00:15,967 SEVERE [javax.enterprise.resource.webcontainer.jsf.flow] (MSC service thread 1-4) Unable to obtain CDI 1.1 utilities for Mojarra
2021-06-14 13:00:15,971 SEVERE [javax.enterprise.resource.webcontainer.jsf.application.view] (MSC service thread 1-4) Unable to obtain CDI 1.1 utilities for Mojarra
Warnings:
2021-06-14 13:00:16,770 INFO [org.ejbca.core.ejb.StartupSingletonBean] (ServerService Thread Pool -- 94) Init, EJBCA 7.4.3.2 Community (67479006a69140e81d66e39871bed8255362effc) startup.
2021-06-14 13:00:16,780 WARN [io.undertow.servlet] (ServerService Thread Pool -- 66) UT015020: Path /* is secured for some HTTP methods, however it is not secured for [HEAD, POST, GET]
2021-06-14 13:00:16,780 WARN [io.undertow.servlet] (ServerService Thread Pool -- 73) UT015020: Path /* is secured for some HTTP methods [...]
During startup WildFly should log something like the following, so you can verify that WildFly is configured to listen on ports for all IPs.
16:58:12,890 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0006: Undertow HTTPS listener httpspriv listening on 0.0.0.0:8443
16:58:12,920 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0006: Undertow HTTPS listener httpspub listening on 0.0.0.0:8442
You can also try connecting to port 8442, to check that the problem is not that you don't have the client certificate in your browser.

Chilkat HTTP with https

I'm currently using the Chilkat HTTP ActiveX control (version 9.3.2.0) with VB6... One of the servers where I download files from is switching over to https, but I can't get it to work... Using http it works perfectly, but when I change the URL to https it returns 0.
Here is the result of Http.LastErrorText:
ChilkatLog:
Download:
DllDate: Aug 5 2012
UnlockPrefix: **********
Username: BILL-DESKTOP:Bill
Architecture: Little Endian; 32-bit
Language: ActiveX
VerboseLogging: 0
backgroundThread: 0
url: https://nomads.ncep.noaa.gov/cgi-bin/filter_gfs_0p25.pl?file=gfs.t12z.pgrb2.0p25.f000&lev_10_m_above_ground=on&lev_2_m_above_ground=on&lev_entire_atmosphere=on&lev_entire_atmosphere_%5C%28considered_as_a_single_layer%5C%29=on&lev_mean_sea_level=on&lev_surface=on&var_APCP=on&var_PRMSL=on&var_TCDC=on&var_TMP=on&var_UGRD=on&var_VGRD=on&leftlon=0&rightlon=360&toplat=90&bottomlat=-90&dir=%2Fgfs.2018120712
toLocalPath: C:\Progra~1\PCGrADS\gfs\grib\gfs_pgrbf_000.grib2
localFileAlreadyExists: 0
QuickGetToOutput_Download:
qGet_1:
simpleHttpRequest_3:
httpMethod: GET
requestUrl: https://nomads.ncep.noaa.gov/cgi-bin/filter_gfs_0p25.pl?file=gfs.t12z.pgrb2.0p25.f000&lev_10_m_above_ground=on&lev_2_m_above_ground=on&lev_entire_atmosphere=on&lev_entire_atmosphere_%5C%28considered_as_a_single_layer%5C%29=on&lev_mean_sea_level=on&lev_surface=on&var_APCP=on&var_PRMSL=on&var_TCDC=on&var_TMP=on&var_UGRD=on&var_VGRD=on&leftlon=0&rightlon=360&toplat=90&bottomlat=-90&dir=%2Fgfs.2018120712
Connecting to web server...
httpServer: nomads.ncep.noaa.gov
port: 443
Using HTTPS.
ConnectTimeoutMs_1: 10000
calling ConnectSocket2
IPV6 enabled connect with NO heartbeat.
connectingTo: nomads.ncep.noaa.gov
dnsCacheLookup: nomads.ncep.noaa.gov
Resolving domain name (IPV4)
GetHostByNameHB_ipv4: Elapsed time: 140 millisec
myIP_1: 192.168.1.38
myPort_1: 55564
connect successful (1)
clientHelloMajorMinorVersion: 3.1
buildClientHello:
majorVersion: 3
minorVersion: 1
numRandomBytes: 32
sessionIdSize: 0
numCipherSuites: 10
numCompressionMethods: 1
--buildClientHello
TlsAlert:
level: fatal
descrip: handshake failure
--TlsAlert
Closing connection in response to fatal error.
Failed to read incoming handshake messages. (1)
Client handshake failed. (3)
Failed to connect to HTTP server.
connectElapsedMs: 640
--simpleHttpRequest_3
--qGet_1
--QuickGetToOutput_Download
bFileDeleted: 1
totalElapsedMs: 672
ContentLength: 0
Failed.
--Download
--ChilkatLog
What am I doing wrong?
Regards,
Bill
You were using an old version from 2012, which did not yet implement TLS 1.2. Chilkat has since added support for TLS 1.2 (for many years now) and the latest version should work fine.

Could not connect to Realm Object Server 2.0

I install ROS on my server, but when I called ros start and it will running at my server, here is the log:
login as: root
root#*.*.*.*'s password:
Welcome to Ubuntu 16.04.3 LTS (GNU/Linux 4.4.0-109-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
root#iZwz940pq66re8qvh8adzuZ:~# ros start
info: Loaded feature token capabilities=[Sync], expires=Wed Apr 19 2017 22:15:29 GMT+0800 (CST)
info: Realm Object Server version 2.5.1 is starting
info: [sync] Realm sync server started ([realm-core-4.0.4], [realm- sync-2.1.10])
info: [sync] Directory holding persistent state: /root/data/sync/user_data
info: [sync] Operating mode: master_with_no_slave
info: [sync] Log level: info
info: [sync] Download log compaction is enabled
info: [sync] Max download size: 131072 bytes
info: [sync] Listening on 127.0.0.1:35571 (sync protocol version 22)
info: Realm Object Server has started and is listening on http://0.0.0.0:9080
But when I entered the address in the browser, It told me that I could not connect.And I use Realm Studio to connect it also tell me that could not reach the server, did i forget something steps? Maybe my server's security policy forbide the port?
Per to the log description, Realm Object Server has started and is listening on http://0.0.0.0:9080.
Please ensure you've allowed TCP port 9080 in your ECS security group.
For detail steps, please refer the document
Add a security group rule

client failing to connect to ldap server

I am new to using ldap and slapd and I am having some trouble getting my client machine to connect to the server that is hosting slapd.
here is the run down:
on a ubuntu box I have an instance of virtualbox running a vm with CentOS. I have installed and configured slapd on the CentOS vm and as long as I am on the vm I can use the ldapsearch, ldapadd, etc. once I move to the client machine (the ubuntu distro housing the vm) I run the following:
ldapsearch -x -LLL -b 'dc=example,dc=com' 'uid=Al' -d 255 -H ldap://192.168.1.73:389/
and the following is what I get
ldap_url_parse_ext(ldap://192.168.1.73:389/)
ldap_create
ldap_url_parse_ext(ldap://192.168.1.73:389/??base)
ldap_pvt_sasl_getmech
ldap_search
put_filter: "(objectclass=*)"
put_filter: simple
put_simple_filter: "objectclass=*"
ldap_build_search_req ATTRS: supportedSASLMechanisms
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 192.168.1.73:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.73:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_close_socket: 3
ldap_msgfree
ldap_err2string
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
I can connect to the vm via ssh and run the ldapsearch, so connecting shouldn't be an issue. I have configured the router to make the machines ip's static (both the vm and the physical)
any help I could get would be very appreciated.
Thanks,
Al
Firewall? It wouldn't be inconceivable that out of the box the firewall would allow ssh through but not ldap. You also need to verify that your ldap server is configured to listen on the outside interface and not just the loop back. Openldap logging can also be setup to be very verbose about the connections it is receiving. You should do that and monitor your syslog while attempting to connect. That should give you enough information to figure out where the connection is being blocked.

Resources