Le pseudo-terminal ne sera pas alloué car stdin n'est pas un terminal


14

J'essaie de configurer le saut SSH automatique via un serveur qui n'a pas nc.

Cela fonctionne à partir de la ligne de commande:

ssh -A gateway ssh steve@target

(J'ai ajouté ma clé publique à l'agent SSH).

Cependant, l'ajouter à ~ / .ssh / config ne:

Host target
  User steveb
  ProxyCommand ssh -A gateway ssh steve@targetip

$ ssh target
Pseudo-terminal will not be allocated because stdin is not a terminal.


^CKilled by signal 2.

Tenter de forcer le problème avec -test amusant mais inutile.

ProxyCommand ssh -A -t gateway ssh steve@targetip

$ ssh target
Pseudo-terminal will not be allocated because stdin is not a terminal.
Pseudo-terminal will not be allocated because stdin is not a terminal.


^CKilled by signal 2.

Plus -t? Pas bien.

ProxyCommand ssh -A -t -t gateway ssh steve@targetip

$ ssh target
tcgetattr: Inappropriate ioctl for device


^CKilled by signal 2.

Est-ce possible? La plupart des didacticiels (par exemple http://www.arrfab.net/blog/?p=246 ) suggèrent d'utiliser nc.


La conclusion est-elle que Netcat est nécessaire?
MountainX-for-Monica

Ça y ressemble. Dans ce cas, j'ai pu l'installer, résoudre mon problème - mais je n'ai pas toujours ce luxe.
Steve Bennett

Voir ma réponse ci-dessous pour deux façons dont j'ai pu le faire sans netcat.
MountainX-for-Monica

Réponses:


13

SSH ProxyCommand sans netcat

Le ProxyCommand est très utile lorsque les hôtes ne sont accessibles qu'indirectement. Avec netcat, c'est relativement droit vers l'avant:

ProxyCommand ssh {gw} netcat -w 1 {host} 22

Ici, {gw} et {host} sont des espaces réservés pour la passerelle et l'hôte.

Mais c'est également possible lorsque netcat n'est pas installé sur la passerelle:

ProxyCommand ssh {gw} 'exec 3<>/dev/tcp/{host}/22; cat <&3 & cat >&3;kill $!'

Le / dev / tcp est une fonction intégrée de bash standard. Les fichiers n'existent pas. Pour vérifier si bash a cette fonctionnalité intégrée, utilisez run:

cat < /dev/tcp/google.com/80 

... sur la passerelle.

Pour vous assurer que bash est utilisé, utilisez:

ProxyCommand ssh {gw} "/bin/bash -c 'exec 3<>/dev/tcp/{host}/22; cat <&3 & cat >&3;kill $!'"

Et cela fonctionne même avec ControlMaster.

(Mis à jour le 22 octobre pour inclure kill pour nettoyer le chat de fond) (Mis à jour le 3 mars 2011 pour rendre les espaces réservés plus clairs et expliquer / dev / tcp)

100% de crédit à Roland Schulz. Voici la source:
http://www.rschulz.eu/2008/09/ssh-proxycommand-without-netcat.html
voir plus d'informations utiles dans les commentaires là-bas.

Il y a aussi plus ici:
http://www.linuxjournal.com/content/tech-tip-tcpip-access-using-bash
http://securityreliks.securegossip.com/2010/08/enabling-devtcp-on-backtrack -4r1ubuntu /

MISE À JOUR : voici quelque chose de nouveau de Marco

En référence à un ProxyCommand dans ~ / .ssh / config où l'on a une ligne comme celle-ci:

ProxyCommand ssh gateway nc localhost %p

Marco dit:

Vous n'avez pas besoin de netcat si vous utilisez une version récente d'OpenSSH. Vous pouvez remplacer nc localhost% p par -W localhost:% p.

Le résultat ressemblerait à ceci:

ProxyCommand ssh gateway -W localhost:%p

8

Grand T, pas petit t.

-T' Disable pseudo-tty allocation.
-t' Force pseudo-tty allocation. 

Mon script renvoyait ce message et ne le fait plus.

/usr/bin/ssh -T -q -i $HOME/.ssh/one_command other_system

J'utilise le authorized_keyon the other_system pour provoquer l'exécution d'une commande:

from="my.mydomain.com",command="bin/remotely-run" ssh-rsa ... 

3

Essayez ceci:

ProxyCommand ssh -A -t gateway ssh -t steve@targetip

Attendez, en quoi est-ce différent de ce que j'ai essayé?
Steve Bennett

@SteveBennett La différence est que cela n'essaie pas seulement d'allouer un ATS sur le deuxième système mais aussi sur le premier.
Hauke ​​Laging du

c'est exactement la même commande que j'ai mentionnée avec le résultat "amusant mais inutile"?
Steve Bennett

@SteveBennett Je l'ai mal lu, en effet. Mon but était d'avoir le -tdans les deux connexions et je l'ai vu dans le mauvais. J'ai modifié ma réponse.
Hauke ​​Laging

Ah. Eh bien, toujours pas bon. J'ai essayé toutes les combinaisons.
Steve Bennett

-3

Vous pouvez essayer la technique suivante de ssh'ing dans server1 suivie de ssh'ing dans server2.

$ ssh -t user1@server1 ssh -t user2@server2 

Le faire comme ça fonctionne pour moi.


1
Veuillez expliquer plus ... Que fait cette commande et comment il est utile de résoudre la réponse.
Tejas du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.