Dipende da cosa l'utente può fare con l'accesso SSH. Se è limitato a azioni specifiche come scp / sftp, port forwarding selezionato o esecuzione di comandi selezionati, il rischio potrebbe essere piccolo. Se invece l'utente ha accesso completo alla shell, può utilizzare gli attacchi di escalation dei privilegi locali per elevare i suoi privilegi da un utente normale a un utente di sistema. Bug che consentono a tali attacchi di essere rilevati regolarmente e alcuni di questi si nascondono per molti anni senza essere pubblicamente conosciuti e risolti.
Oltre a tali escalation di privilegi diretti, un utente con accesso alla shell può anche connettersi a servizi di rete che sono esplicitamente limitati dall'accesso esterno e che potrebbero non essere così ben protetti perché il rischio è considerato basso. Questo potrebbe ad esempio essere installazioni di database locali con password non sicure e facilmente forzate. E a parte i sistemi locali, l'utente potrebbe ottenere l'accesso ai sistemi interni sulla stessa rete che di solito sono protetti dall'esterno usando un firewall.
E, naturalmente, un utente con una shell di login potrebbe esaurire le risorse di sistema come la memoria, il tempo della CPU, l'I / O o lo spazio su disco a meno che non siano impostati limiti specifici sull'account.
Questi sono solo i problemi più ovvi. Notate che la maggior parte di questi potrebbe anche essere già eseguita all'interno di uno script PHP o di un simile codice lato server in controllo dell'utente.
In sintesi: se ci sono dati sensibili sul sistema o su sistemi connessi e raggiungibili non fornire un modo per un utente non fidato di eseguire codice arbitrario come utente non privilegiato. Ciò implica l'accesso alla shell ma potrebbe anche implicare l'utilizzo di propri script PHP o simili. Se tale esecuzione del codice è necessaria, puoi provare a mitigare il rischio aggiungendo ulteriori livelli di sicurezza, come sandbox, container o simili, ma nota che queste restrizioni non sono neanche infrangibili.