Suppongo che usi i tasti SSH come autenticazione? La riautenticazione e gli scambi di chiavi avvengono continuamente durante il protocollo SSH, quindi avere una sessione attiva è abbastanza sicuro.
Un'altra cosa è la conferma, ad esempio, vuoi che l'utente voglia davvero commettere un'azione che potrebbe essere irreversibile. Diciamo che cancelliamo qualcosa.
Per risolvere questo problema, ti suggerirei di mostrare semplicemente un codice casuale a 6 cifre sullo schermo e chiedere all'utente di ridigitarlo per indicare "SÌ". (e considera "NO" se il codice a 6 cifre era errato o non è stato scritto alcun codice.)
In questo modo:
Are you really sure you want to delete the database records_2013.db?
If NO, just press ENTER now.
If YES, type the following code - 193619 - here, and press ENTER: _
Questo risolve quindi perfettamente il tuo problema, dal momento che il server / client SSH si accerterà che abbia una connessione autenticata valida al server, il che significa che un utente malintenzionato non può dirottare una sessione SSH autenticata e il codice di conferma casuale, quindi assicura il l'utente non commette, per errore, un'operazione pericolosa.
Si noti che questo codice non è considerato un captcha, quindi non ostacola le presentazioni automatiche. Ma reauth by ssh-keys non risolverà neanche questo.
Il codice è proprio lì, quindi l'utente si ferma e pensa molto attentamente se vuole procedere prima di procedere.
Il motivo per cui le banche utilizzano uno schema di riautenticazione, è che le sessioni possono essere dirottate poiché HTTP / HTTPS è un protocollo stateless (la connessione viene chiusa dopo l'invio della pagina, rendendo difficile l'uso del protocollo sottostante per l'autenticazione di sessione), ma anche per la seconda ragione, per impedire agli utenti di erroneamente, inviare denaro da qualche parte che non intendevano.