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.

Steve Bennett
la source
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
MountainX-for-Monica
la source
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 ... 
user46083
la source
3

Essayez ceci:

ProxyCommand ssh -A -t gateway ssh -t steve@targetip
Hauke ​​Laging
la source
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.

Jan Marius Evang
la source
1
Veuillez expliquer plus ... Que fait cette commande et comment il est utile de résoudre la réponse.
Tejas du