Votre mot de passe SSH n'est pas un mot de passe SOCKS

Vous avez saisi un mot de passe pour démarrer ssh -D. Il a authentifié votre connexion SSH. Il n'a pas créé de compte SOCKS protégé par mot de passe pour chaque programme pouvant atteindre le nouvel écouteur.

Le transfert dynamique d'OpenSSH fournit un service SOCKS local sur un transport SSH authentifié. Son traitement SOCKS5 choisit la méthode sans authentification ; ce n'est pas un serveur SOCKS général à nom d'utilisateur et mot de passe.

Pour un usage personnel, liez localement :

ssh -N -D 127.0.0.1:1080 [email protected]

Les applications de cet ordinateur utilisent le port 1080 sans saisir votre mot de passe SSH comme mot de passe SOCKS. La documentation du transfert dynamique décrit l'écouteur, et le code de traitement SOCKS d'OpenSSH fournit le détail de l'authentification.

Le partage change le problème

Lier à une adresse LAN rend le port joignable au-delà de l'usage local d'origine. Les clients proches n'établissent pas de sessions SSH distinctes simplement parce que leur trafic passe par le vôtre. Si le réseau autorise l'accès, ces clients peuvent partager l'identité extérieure de votre passerelle.

Un pare-feu peut restreindre les clients joignables, mais n'ajoute pas d'échange de connexion SOCKS. Pour des noms d'utilisateur SOCKS, des quotas ou des règles par utilisateur distincts, choisissez un serveur prenant en charge ces fonctions. Dante, par exemple, documente l'authentification SOCKS séparément des restrictions d'adresse client.

Cela aide aussi au dépannage. Un client qui insiste sur la méthode nom d'utilisateur/mot de passe SOCKS peut ne pas négocier avec cet écouteur comme prévu. Adaptez l'application ou choisissez un service SOCKS authentifié approprié ; réessayer votre mot de passe SSH revient à viser la mauvaise connexion.

L'accessibilité purement locale reste une frontière à comprendre, non l'affirmation que chaque processus de l'ordinateur local appartient au même utilisateur.