Le problème 1.0
Je travaille sur un serveur qui ne prend en charge que l'authentification à deux facteurs (l'authentification par paire est désactivée). Donc, chaque fois que mon client SFTP veut télécharger un fichier, il me demande un token ... après 3 minutes, cela devient un UX not_very_nice.
La solution 1.0
J'ai donc appris le multiplexage SSH et maintenant je peux ouvrir une connexion maître manuellement (à partir du terminal), et toutes les autres connexions ssh peuvent être multiplexées en haut, comme ceci:
$ ssh example_com_master
Verification code: (/me enters the token code)
Password: (/me enters my pass)
Welcome to Ubuntu 14.04 blah blah....
Last login: Wed Oct 1 11:24:15 2014 from 12.34.56.78
$
Ensuite, à partir d'un autre terminal ou d'un autre logiciel:
$ ssh my.example.com
Last login: Wed Oct 1 16:34:45 2014 from 12.34.56.78
$
Donc, mission accomplie, plus de jeton 2FA. Et pas de mot de passe, d'ailleurs, SSH FTW!
~ / .ssh / config:
Host example_com_master
HostName my.example.com
User username
PubkeyAuthentication no
ControlMaster yes
ControlPath ~/.ssh/sockets/example_com
ControlPersist 10
Host my.example.com
HostName my.example.com
User username
PubkeyAuthentication no
ControlMaster no
ControlPath ~/.ssh/sockets/example_com
Problème 2.0 (TLDR)
Certains logiciels (par exemple PyCharm IDE) utilisent leur propre bibliothèque SSH / binaire / peu importe! Ce qui signifie que rien que je tape ~/.ssh/config
ne l'affectera, AFAIK.
C'est mon problème actuel: existe-t-il un moyen de "tromper" ces logiciels pour qu'ils utilisent une connexion principale déjà existante?
Une idée: parce que vous pouvez généralement configurer un logiciel pour utiliser un autre port auquel vous connecter, je me demandais s'il était possible de configurer une sorte de tunneling qui multiplexerait les connexions entrantes sur le maître existant. Mais mon foo m'a échoué ...
Éditer:
Le but principal est de se connecter à un interpréteur / débogueur Python distant.
modifier 2:
Tous les ports sont fermés autres que 22 et 80. Il est cependant possible de faire:
remote$ ssh localhost:2222
(password or securekey login, both work)
remote$
mais 2222 n'est ouvert que pour les connexions de l'hôte local, et les administrateurs n'ouvriront aucun port supplémentaire, disant que "n'importe qui pourrait l'utiliser".