Software Client FTP / SDIFTP

Il problema è che i sistemi Windows non prevedono il concetto di Chroot jail nativo, e quindi devi forzare tu il SO operativo, ed è un casino. Se invece imposti ForceCommand internal-sftp allora ssh non riesce nemmeno a loggarsi ad entrare mentre sftp continua a funzionare correttamente. Di questo problema ne parlavano gli sviluppatori OpenSSH e credo che ci stiano lavorando su.

1 Mi Piace

Ah ora ho capito! :slight_smile:
Di Windows sono ignorante totale :grimacing:

Un bagno di sangue, Federico; spero di uscirne vivo :smiley:

1 Mi Piace

Lascia stare, siamo tutti sulla stessa barca, nelle mani di Sogei… :rofl:

Ciao, hai avuto risposta a riguardo?

Edit: da https://www.fatturapa.gov.it/export/fatturazione/it/b-2.htm
Si precisa che il file archivio non deve essere firmato ma devono essere firmati, invece,tutti i file FatturaPA al suo interno.

Per quanto riguarda i file in entrata, sono i file fattura ad essere cifrati oppure tutto l’archivio?

Dal manuale Sogei i file in entrata avranno estensione .zip.p7m.enc quindi credo che prima zippino tutto e poi firmano e cifrano il file zip.
Fonte : Istruzioni per il servizio SDIFTP (ver.4.0) sezione 5.1.1 a pag.19.
Attenzione per File in Entrata si intendono in Uscita dallo SDI e in entrata per noi.

Salve, accreditando il canale SDIFTP, da Sogei hanno riscontrato il seguente problema
debug1: Authenticating to xx:xx:xx:xx as ‘XX’
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:mkeWygZbr+9ys4HeFD2FAhdaS6y/aeDgyFtEaWb6Deo
Host key verification failed.
Couldn’t read packet: Connection reset by peer

Qualcuno ha avuto lo stesso problema, oppure sa come risolverlo? Grazie.

Si, pare sia colpa di una anomalia lato Sogei; ho avuto anch’io lo stesso problema ma da questo pomeriggio è scomparso da solo. Penso basta solo attendere,

La Sogei lo ha riscontrato nel primo pomeriggio, @matr1x quando si è risolto, più o meno?

Nel mio caso intorno alle 12:30 / 13:00; alle 13:02 mi è arrivata la prima notifica di lettura del supporto, ma adesso sembra di nuovo fuori uso, non legge più. Ufficialmente hanno dichiarato che le anomalie sarebbero terminate domani, magari stanno ancora sistemando.

Grazie mille per la risposta

Mi dareste una mano, per favore ? Mi fareste una piccola Flowchart su come preparare il file supporto .zip? I singoli file fattura .xml devono essere firmati e cifrati ? e che nome devono avere ? Il file archivio .zip, che contiene i singoli file .xml, deve essere firmato e cifrato ? La documentazione dice tutto e il contrario di tutto, avrei bisogno di un aiuto da qualcuno che ha già inviato i files correttamente, grazie.

A quanto ho capito, devono essere firmati i file fattura e non gli archivi, mentre i supporti in entrata sono firmati e cifrati

Manuale Specifiche Tecniche FTP 4.0 dice :
5.2.2 FILE VERSO SDI
Se il Nodo 12345678901 produce, alle ore 12:30 del 15 Gennaio 2012, un supporto da inviare al SdI, il flusso prevede i seguenti passaggi:
 al supporto viene attribuito il nome FI.12345678901.2012015.1230.900.zip, come previsto dalla nomenclatura;
 il Nodo applica la firma elettronica e la cifratura sul file prodotto;
 il Nodo sposta (o rinomina) il file FI.12345678901.2012015.1230.900.zip nella directory DatiVersoSdITest ;
 SdI preleva dalla directory DatiVersoSdITest il supporto FI.12345678901.2012015.1230.900.zip e al termine del trasferimento lo rimuove;
 SdI effettua i controlli di quadratura e produce il file di esito EO.12345678901.2012015.1230.900.xml.

Penso per file prodotto intenda il file fattura e non l’archivio

Io ho proceduto in questo modo :

  • genero i singoli file fattura in formato .xml, con nomi interni
  • genero il file quadratura in formato .xml con lo stesso nome del supporto.zip, rispettando le regole del naming del file (FI. etc etc );
  • metto tutti i file .xml dentro il file .ZIP, quindi zippandoli;
  • firmo e cifro il file .zip, senza modificarne l’estensione .zip
  • invio il file .zip;
    Risultato : pare vada tutto bene tranne che per l’errore “File di quadratura non trovato”;
    Avete dei suggerimenti ? Grazie in anticipo …
    Più che altro ero curioso di sapere se il procedimento era corretto, ed era solo un problema di file di quadratura …

Ho proceduto come hai fatto tu ma:

  • firmo il file xxx.zip, ottenenendo quindi un file xxx.zip.p7m
  • cifro il file xxx.zip.p7m, ottenendo quindi un file xxx.zip.enc
  • invio il file xxx.zip.enc nella cartella

Il tuo errore però parla di ‘file quadratura non trovato’, sicuro che abbia lo stesso identico nome del file zip che stai inviando?

da https://fatturapa.gov.it/export/fatturazione/it/b-2.htm
“Si precisa che il file archivio non deve essere firmato ma devono essere firmati, invece,tutti i file FatturaPA al suo interno.”
Non so come comportarmi.

Esatto, mentre qui dice :
Se il Nodo 12345678901 produce, alle ore 12:30 del 15 Gennaio 2012, un supporto da inviare al SdI, il flusso prevede i seguenti passaggi:
 al supporto viene attribuito il nome FI.12345678901.2012015.1230.900.zip, come previsto dalla nomenclatura;
 il Nodo applica la firma elettronica e la cifratura sul file prodotto;

“La nomenclatura del file di quadratura corrisponde a quella del supporto ed assume l’estensione .xml”