Quando esegui:
ssh -A -t [email protected]
stai stabilendo una sessione tra desktop e bar.com . D'ora in poi, tutto ciò che scrivi in questa sessione viene interpretato e eseguito su bar.com .
Quindi stabilisci una sessione da bar.com a server ( sls non è un comando standard, ma presumo che sia un wrapper per un'altra connessione SSH).
Hai una seconda sessione crittografata tra bar.com e server . Questa sessione è autenticata con la tua chiave privata che è memorizzata sulla macchina desktop .
Nel primo comando hai l'argomento -A che abilita l'inoltro dell'agente . Questo meccanismo consente di crittografare la sessione tra bar.com e il server, utilizzando la macchina desktop (e la chiave privata memorizzata lì) per l'autenticazione.
Non significa che la seconda connessione sia codificata end-to-end tra desktop e server , significa solo desktop autorizzato una sessione tra bar.com e server .
La situazione non può essere paragonata ad un attacco, perché hai deliberatamente scelto di utilizzare la funzione per tua comodità e sicurezza (la tua chiave privata non lascia la tua macchina, non puoi archiviare un'altra chiave con accesso a server su bar.com , non devi digitare la password).
La funzionalità che apparentemente si aspettava si chiama tunneling o port forwarding (anche se deve essere configurata separatamente) . Con questo si stabiliscono due sessioni SSH da desktop prima a bar.com poi un altro a una diversa porta di bar.com che sarebbe "vincolato" alla porta 22 di server . In questo scenario bar.com non avrebbe la possibilità di vedere "dentro" la sessione SSH tra desktop e server .