Admitting defeat

[Altocumulus]

I have had, for a long while a custom version website that was generated from Cumulus.

Since last weekend I have gradually moved across lock stock and wotsit to MX - having run them side by side for a long while.

I am starting, effectively from scratch again - brain cells somewhat less clear than once were, it seems.

Following the wiki I have uploaded the content of the MX /webfiles folder to the server, same as previously in Cumulus.

FTP settings are all set according to the 'Standard Web Site' option in settings.

Local /web folder is refreshing with updated files.

Server side; realtime.txt and realtimeguages.txt are both updating at one minute intervals.

If I go to the website address all I get is a static blank template - I must be doing something simply wrong but nothing else on the server is being updated. I've scoured the wiki and read instructions on both the Cumulus and CumulusMX sections on websites, and I can't see what it is I haven't done!
Logging confirms what I can already see, only the realtime text files are being ftp'd to the server.

Geoff

[water01]

OK if you are using the standard website have you ticked "I want to use the supplied default web site" in Internet Settings / Web/FTP Site / Interval Configuration (don't forget to scroll down to the bottom and Save Settings!!) ? That should set everything required.

Also a URL of your website would allow us to see it and offer further suggestions.

[Altocumulus]

OK if you are using the standard website have you ticked "I want to use the supplied default web site" in Internet Settings / Web/FTP Site / Interval Configuration (don't forget to scroll down to the bottom and Save Settings!!) ? That should set everything required.

Also a URL of your website would allow us to see it and offer further suggestions.

Thanks David, and yes, all the appropriate settings are both set and saved. Entry into the website yields static templates with no data.

Apart from an index.php* which alerts to the site being under maintenance, the only files in the html_public folder on the server are those FTZ'd from
CumulusMX / webfiles plus the realtime.txt and realtimeguages.txt.

( * left over from previous website - I change the name to test index.html )

The latter imply ftp'ing is OK, but otherwise mmmm!

craigdamwx.info

[Altocumulus]

Ah.

Commented too soon the 'realtime....' files are not updating.

I can copy to a local folder, so that tests out OK.

Only thing to double check is the ftp protocol required at the server. I have been using 0 - FTP (plain old FTP).

Mind, a quick test using the other two options didn't succeed....!

[Altocumulus]

Looks suspiciously like it's to do with which FTP setting is acceptable to the host.

Option 1 is rejected by the server and yet it's in their own documentation as being acceptable.

( Shame the MX logging doesn't indicate which of the FTP settings is being used.... )

Will have to dig deeper and try each setting over an hour or so and see if one definitely works.

[Altocumulus]

Looks like a call to the host...From MX logs....


0-FTP Plain - "Cleartext sessions not allowed"

1-FTPS - "No connection can be made, target refused"

2-SFTP - "Invalid Sshftp Authorisation"

[HansR]

For SFTP you have to realise that only un/pw does not appear to work under installations known to me, it does require a key pair.
FTPS is known not to work for some servers.

The only FTP technique known to work always is plain FTP.
Once you have that working, only then I would advise to try the others.

And indeed communicate with your provider.

[mcrossley]

For SFTP you have to realise that only un/pw does not appear to work under installations known to me, it does require a key pair.

Hmm, works for me to my internal SFTP server.

Code: Select all

# Connect()
Status:   Connecting to 192.168.1.131:21
Response: 220 XXX FTP server ready.
Command:  AUTH TLS
Response: 234 AUTH TLS command successful.
Status:   FTPS Authentication Successful
Status:   Time to activate encryption: 0h 0m 0s.  Total Seconds: 0.1027554.
Command:  USER <Username>
Response: 331 Password required for <Username>
Command:  PASS ***
Response: 230 User <Username> logged in, access restrictions apply.
Command:  PBSZ 0
Response: 200 PBSZ command successful (PBSZ=0).
Command:  PROT P
Response: 200 Protection level set to Private.
Command:  FEAT
Response: 211 End.
Response: 211- Extensions supported:
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: CCC
Response: SIZE
Response: MDTM
Response: REST STREAM
Response: MFMT
Response: TVFS
Response: MLST
Response: MLSD
Response: UTF8
Status:   Text encoding: System.Text.UTF8Encoding
Command:  OPTS UTF8 ON
Response: 200 OK, UTF-8 enabled
Command:  SYST
Response: 215 UNIX Type: L8
Status:   Auto-detected UNIX listing parser

# GetWorkingDirectory()
Command:  PWD
Response: 257 "/" is current directory.

[HansR]

Hmm, works for me to my internal SFTP server.

If tried it for me to my provider: did not work (same for v4 btw)
@sutne has the same issue already for a long time (don't know why he can't use a key btw)

I can't personally try other examples but maybe there are others who may report the non-functioning of un/pw (with or without key btw) under SFTP.

And for the un/pw with my provider, I tried again and got:

Code: Select all

2021-12-04 13:53:10.126 RealtimeSSHLogin: Error connecting SFTP - No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic).
2021-12-04 13:53:10.151 Exception = Renci.SshNet.Common.SshAuthenticationException: No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic).
   at Renci.SshNet.ClientAuthentication.Authenticate(IConnectionInfoInternal connectionInfo, ISession session)
   at Renci.SshNet.ConnectionInfo.Authenticate(ISession session, IServiceFactory serviceFactory)
   at Renci.SshNet.Session.Connect()
   at Renci.SshNet.BaseClient.Connect()
   at CumulusMX.Cumulus.RealtimeSSHLogin()

[freddie]

Code: Select all

No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic)

Isn't this the list of authentication methods returned by the server? It doesn't contain anything that will handle username/password auth.

[HansR]

Code: Select all

No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic)

Isn't this the list of authentication methods returned by the server? It doesn't contain anything that will handle username/password auth.

That's probably why un/pw does not work
But anyway: it is clear that not all login methods work everywhere.

[water01]

For SFTP you have to realise that only un/pw does not appear to work under installations known to me, it does require a key pair.

Hmm, works for me to my internal SFTP server.

And for me connecting to my external host. You might want to check what port to use as my hosting service uses port 3784.

[HansR]

And for me connecting to my external host. You might want to check what port to use as my hosting service uses port 3784.

I'll do that... (now using port 22 for the key authorisation)

[Altocumulus]

I'm using the default ports given in MX.

FZ doesn't fill in the port number when I manually transfer files. It stipulates explicit FTP over TLS if available.

There's nothing specific on the host docs, other than the explicit FTP as above.

I suspect they may have blocked me for some reason, especially as the realtime files were being accepted for a while.

[HansR]

Code: Select all

No suitable authentication method found to complete authentication (publickey,gssapi-keyex,gssapi-with-mic)

Isn't this the list of authentication methods returned by the server? It doesn't contain anything that will handle username/password auth.

Yes it is and I just confirmed with my provider that they do not accept un/pw on SFTP as login method because of their high security standards.
So it simply cannot be done there (and probably other providers use the same higher security standards).

For SFTP you have to realise that only un/pw does not appear to work under installations known to me, it does require a key pair.

Hmm, works for me to my internal SFTP server.

And for me connecting to my external host. You might want to check what port to use as my hosting service uses port 3784.

See my answer above to @freddie. So it is not the port, it is simply the provider.
So when a user can't connect the first question should be: does the provider allow it?