Le transfert SSH SOCKS est distinct des erreurs de périphérique TUN
Reconnaître un écouteur SOCKS établi même lorsque la même session SSH échoue ensuite à créer un périphérique TUN séparé.
Ces deux observations peuvent coexister dans un même journal SSH :
Local forwarding listening on 127.0.0.1 port 1080.
Tunnel device open failed.La première concerne un écouteur SOCKS dynamique. La seconde concerne un périphérique réseau de tunnel. Ce sont des demandes de transfert distinctes.
OpenSSH utilise -D pour le transfert dynamique au niveau applicatif et -w pour les périphériques de tunnel. Un réglage Tunnel peut aussi demander ce dernier via la configuration. L'échec d'obtention des privilèges ou de l'autorisation serveur pour un périphérique TUN ne prouve pas en soi que l'écouteur SOCKS antérieur n'a jamais été créé.
Lisez ce qui a réussi avant l'erreur : l'authentification SSH, la création de l'écouteur et toute demande ultérieure de canal de destination. Un port SOCKS en écoute a toujours besoin d'un client compatible et d'une destination joignable et autorisée. C'est une preuve portant sur une étape.
Si le travail visé est uniquement le transfert SOCKS, examinez pourquoi un périphérique de tunnel a été demandé. Une configuration restreinte peut désactiver cette demande sans rapport :
ssh -N -o Tunnel=no -D 127.0.0.1:1080 [email protected]Conservez les vérifications habituelles de clé d'hôte et de compte SSH. Rien ne justifie d'accorder des privilèges de périphérique réseau simplement pour taire une erreur liée à une fonction dont la route SOCKS n'a pas besoin.