App File o un'app separata
L'app File ha un comando Connetti al server, ma serve per server di condivisione file come le cartelle SMB. Non offre SFTP, quindi per raggiungere un server via SSH ti serve un'app client SFTP.
Le app differiscono in come si integrano con l'app File. Alcune aggiungono una propria posizione, e puoi esplorare il server da dentro File. Altre tengono i download in una cartella propria, che compare sotto Su iPhone. Controlla quale ottieni, perché decide come apri un file in altre app.
Cosa cercare in un'app
- Login con chiave, con chiavi Ed25519 e una passphrase.
- Controlli sulla chiave host, con un blocco quando la chiave cambia.
- Caricamenti da Foto e File, perché è lì che stanno i file del telefono.
- Comportamento in background. iOS può sospendere un'app che esce dallo schermo, quindi un trasferimento grande può fermarsi. Scopri cosa fa l'app, e prova con un file grande.
- Ripresa, così un caricamento fallito su una connessione debole non deve ricominciare da capo.
- Dove conserva i segreti, e se ha un blocco dell'app.
Cosa serve a SFTP sul server
SFTP gira dentro SSH, quindi se SSH funziona ti serve solo un'altra cosa, il sottosistema sftp. Controllalo:
sudo sshd -T | grep -i '^subsystem'
Su Debian stampa subsystem sftp /usr/lib/openssh/sftp-server. Se non compare nulla, i client SFTP falliscono così:
subsystem request failed on channel 0
Connection closed
Per risolvere, aggiungi Subsystem sftp internal-sftp a sshd_config e ricarica sshd. Per raggiungere un server privato da un telefono, vedi SSH da iPhone. Il percorso di rete è lo stesso.
Un utente che può usare SFTP solo in una cartella
Il tuo telefono non ha bisogno di una shell sul server per caricare foto. Un utente dedicato limita il danno se il telefono o la sua chiave vengono persi. Crea il gruppo, l'utente e le cartelle:
sudo groupadd sftponly
sudo useradd -g sftponly -s /usr/sbin/nologin -d /srv/sftp/sftpuser -M sftpuser
sudo mkdir -p /srv/sftp/sftpuser/uploads /srv/sftp/sftpuser/.ssh
sudo chown root:root /srv/sftp /srv/sftp/sftpuser
sudo chmod 755 /srv/sftp /srv/sftp/sftpuser
sudo chown sftpuser:sftponly /srv/sftp/sftpuser/uploads /srv/sftp/sftpuser/.ssh
sudo chmod 700 /srv/sftp/sftpuser/.ssh
Metti al suo posto la chiave pubblica del telefono, da un file che hai copiato sul server:
sudo install -m 600 -o sftpuser -g sftponly iphone.pub /srv/sftp/sftpuser/.ssh/authorized_keys
Non hai ancora una coppia di chiavi? Vedi come generare una chiave SSH Ed25519.
Poi crea /etc/ssh/sshd_config.d/20-sftp.conf:
Match Group sftponly
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
AllowAgentForwarding no
X11Forwarding no
PermitTunnel no
PermitTTY no
Se il tuo sistema non ha sshd_config.d, metti il blocco proprio alla fine di sshd_config, perché un blocco Match lì vale fino alla fine del file. Controlla, poi ricarica:
sudo sshd -t
sudo sshd -T -C user=sftpuser,host=example.com,addr=203.0.113.10 | grep -iE '^(chrootdirectory|forcecommand)'
sudo systemctl reload ssh
Il secondo comando deve stampare forcecommand internal-sftp e chrootdirectory %h, con le maiuscole, come ForceCommand, da OpenSSH 10.4 in poi. Eseguilo di nuovo con un altro nome utente per verificare che gli altri mostrino ancora none. Su Fedora e RHEL il servizio si chiama sshd.
La regola sulla proprietà
È qui che inciampano quasi tutti. Ogni cartella nel percorso del chroot, fino al chroot stesso incluso, deve appartenere a root e non essere scrivibile da gruppo o altri. Quindi l'utente non può scrivere direttamente nella propria cartella principale, ed è per questo che esiste uploads.
Quando abbiamo dato la cartella principale all'utente, il login è fallito con solo questo sul client:
Connection to server closed by remote host.
Connection closed
Il vero motivo è nel log del server:
bad ownership or modes for chroot directory "/srv/sftp/sftpuser"
Provalo prima da un computer
$ sftp sftpuser@server
sftp> pwd
Remote working directory: /
sftp> cd uploads
sftp> put photo.jpg
sftp> cd /
sftp> put photo.jpg
dest open "/photo.jpg": Permission denied
sftp> get /etc/passwd
File "/etc/passwd" not found.
Un login con shell deve fallire, con This service allows sftp connections only. Nella stessa prova, scp verso /uploads ha funzionato, perché usa SFTP, e rsync è fallito, perché deve eseguire un programma sul server. Vedi scp, SFTP o rsync.
Un limite: l'utente possiede .ssh dentro il chroot, quindi chi ha quella chiave può leggere o modificare authorized_keys. Questo non gli dà una shell né accesso fuori dalla cartella, ma potrebbe aggiungere un'altra chiave per questo account. Se ti importa, imposta AuthorizedKeysFile nel blocco Match su un percorso fuori dal chroot.


Domande
L'app File dell'iPhone si collega a un server SFTP?
No. Connetti al server nell'app File serve per i server di condivisione file come SMB, non per SFTP. Per raggiungere un server via SSH serve un'app client SFTP.
Che porta usa SFTP?
La porta SSH, la 22 se il server non è impostato diversamente, perché SFTP viaggia dentro una connessione SSH.
Perché un utente solo SFTP riceve Connection closed subito dopo il login?
Di solito le cartelle del chroot hanno il proprietario sbagliato. Ogni cartella fino al chroot deve essere di root e non scrivibile dagli altri, e il log del server dice bad ownership or modes for chroot directory.
Fonti
- sshd_config(5): ChrootDirectory, ForceCommand, Subsystem, manuale OpenBSD
- sftp(1), manuale OpenBSD
- Connettere server o dispositivi esterni con File su iPhone, Supporto Apple