Alors voila, j'ai lu beaucoup de bien dans ce newsgroup et ailleurs sur le
net de la Terratec Cinergy T² qui en plus est supportée en natif sous
ubuntu.
cf http://doc.ubuntu-fr.org/tnt
Mais j'ai été surpris que ce modèle date de début 2005 alors qu'on est en
mi 2007 et qu'en quasi 3 ans, la technologie a forcément beaucoup évolué.
Je me demande donc si ce modèle n'est pas justement devenu obsolète.
C'est pour ça que je pose la question.
Quelle carte TNT me conseillez vous sous linux ?
Je fais mes SSH en tant que ce que je veux... Mais la bride des 1500 (ou je ne sais combien) premiers ports intouchables sous *nix, c'est sous *nix, hors là, SSH, ça marche aussi avec d'autres trucs hein ;)
~ $ ftp localhost Connecté à THECRASHER. 220 arago-old.xxxxx.xx FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Utilisateur (THECRASHER:(none)) : crash 331 Password required for crash. Mot de passe : 230- Linux arago-old 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User crash logged in. ftp> quit 221 Goodbye.
Aucune chance de faire passer du FTP comme ça.
Ahbon ? Aucune, z'êtes sur ?
C'est censé être quoi, 125 ?
Woops, j'ai dérappé là, toutes mes excuses...
C'est surtout que ça ne marche pas.
On a des avis contraires sur la chose, je suppose ;)
S.
Nicolas George wrote:
Sebastiaan 'CrashandDie' Lauwers wrote in message
ssh -L 21:
Tu fais tes ssh en tant que root ?
Je fais mes SSH en tant que ce que je veux... Mais la bride des 1500 (ou
je ne sais combien) premiers ports intouchables sous *nix, c'est sous
*nix, hors là, SSH, ça marche aussi avec d'autres trucs hein ;)
CrashandDie@THECRASHER ~
$ ftp localhost
Connecté à THECRASHER.
220 arago-old.xxxxx.xx FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17)
ready.
Utilisateur (THECRASHER:(none)) : crash
331 Password required for crash.
Mot de passe :
230- Linux arago-old 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686
230-
230- The programs included with the Debian GNU/Linux system are free
software;
230- the exact distribution terms for each program are described in the
230- individual files in /usr/share/doc/*/copyright.
230-
230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
230- permitted by applicable law.
230 User crash logged in.
ftp> quit
221 Goodbye.
Aucune chance de faire passer du FTP comme ça.
Ahbon ? Aucune, z'êtes sur ?
C'est censé être quoi, 125 ?
Woops, j'ai dérappé là, toutes mes excuses...
C'est surtout que ça ne marche pas.
On a des avis contraires sur la chose, je suppose ;)
Je fais mes SSH en tant que ce que je veux... Mais la bride des 1500 (ou je ne sais combien) premiers ports intouchables sous *nix, c'est sous *nix, hors là, SSH, ça marche aussi avec d'autres trucs hein ;)
~ $ ftp localhost Connecté à THECRASHER. 220 arago-old.xxxxx.xx FTP server (Version 6.4/OpenBSD/Linux-ftpd-0.17) ready. Utilisateur (THECRASHER:(none)) : crash 331 Password required for crash. Mot de passe : 230- Linux arago-old 2.6.18-4-686 #1 SMP Wed May 9 23:03:12 UTC 2007 i686 230- 230- The programs included with the Debian GNU/Linux system are free software; 230- the exact distribution terms for each program are described in the 230- individual files in /usr/share/doc/*/copyright. 230- 230- Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent 230- permitted by applicable law. 230 User crash logged in. ftp> quit 221 Goodbye.
Aucune chance de faire passer du FTP comme ça.
Ahbon ? Aucune, z'êtes sur ?
C'est censé être quoi, 125 ?
Woops, j'ai dérappé là, toutes mes excuses...
C'est surtout que ça ne marche pas.
On a des avis contraires sur la chose, je suppose ;)
Le ftp utilise des connexions annexes sur des ports aloués dynamiquement pour les transferts de données.
Thierry B.
--{ Luc Habert a plopé ceci: }--
Le ftp utilise des connexions annexes sur des ports aloués dynamiquement pour les transferts de données.
Donc, si j'ai bien suivi, on risque de se retrouver avec le flux de contrôle dans le tunnel crypté, et le flux de données en plein vent dans le Ternet mondial ?-)
-- { SIGOURNEY, "WEAVER" }, /* In case of Alien attack. */ --{ f.m.b.l revisite la command kill }--
--{ Luc Habert a plopé ceci: }--
Le ftp utilise des connexions annexes sur des ports aloués dynamiquement
pour les transferts de données.
Donc, si j'ai bien suivi, on risque de se retrouver avec le flux
de contrôle dans le tunnel crypté, et le flux de données en plein
vent dans le Ternet mondial ?-)
--
{ SIGOURNEY, "WEAVER" },
/* In case of Alien attack. */
--{ f.m.b.l revisite la command kill }--
Le ftp utilise des connexions annexes sur des ports aloués dynamiquement pour les transferts de données.
Donc, si j'ai bien suivi, on risque de se retrouver avec le flux de contrôle dans le tunnel crypté, et le flux de données en plein vent dans le Ternet mondial ?-)
-- { SIGOURNEY, "WEAVER" }, /* In case of Alien attack. */ --{ f.m.b.l revisite la command kill }--
Luc.Habert.00__arjf
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion venir de B, donc il va essayer de se connecter au port X de B, sur lequel il n'y a rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le client qui se croit connecté à A va essayer de se connecter au port X de A, et non de C.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et non un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine
locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au
serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion venir
de B, donc il va essayer de se connecter au port X de B, sur lequel il n'y a
rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le
client qui se croit connecté à A va essayer de se connecter au port X de A,
et non de C.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le
protocole ftp, c'est seulement un numéro de port qui est envoyé et non un
couple (IP,port), mais la deuxième possibilité me parait nettement
improbable.
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion venir de B, donc il va essayer de se connecter au port X de B, sur lequel il n'y a rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le client qui se croit connecté à A va essayer de se connecter au port X de A, et non de C.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et non un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
Sebastiaan 'CrashandDie' Lauwers
Luc Habert wrote:
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
En effet, j'ai été piqué au vif, et j'ai pas cherché à comprendre... Double erreur pour moi.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et non un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
Je pense que le plus simple resterait cependant de tout simplement se procurer un client capable de faire du SFTP, même si ça n'est que du scp avec une coquille toute jolie autour, ça reste efficace...
S.
Luc Habert wrote:
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine
locale, B l'intermédiaire, et C la distante.
En effet, j'ai été piqué au vif, et j'ai pas cherché à comprendre...
Double erreur pour moi.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le
protocole ftp, c'est seulement un numéro de port qui est envoyé et non un
couple (IP,port), mais la deuxième possibilité me parait nettement
improbable.
Je pense que le plus simple resterait cependant de tout simplement se
procurer un client capable de faire du SFTP, même si ça n'est que du scp
avec une coquille toute jolie autour, ça reste efficace...
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
En effet, j'ai été piqué au vif, et j'ai pas cherché à comprendre... Double erreur pour moi.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et non un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
Je pense que le plus simple resterait cependant de tout simplement se procurer un client capable de faire du SFTP, même si ça n'est que du scp avec une coquille toute jolie autour, ça reste efficace...
S.
Nicolas George
Sebastiaan 'CrashandDie' Lauwers wrote in message <4691866d$0$21726$:
SFTP, même si ça n'est que du scp avec une coquille toute jolie autour
Ce n'est pas du tout le cas. SFTP est un protocole de manipulation de fichiers distants tout à fait complet, et au passage largement mieux conçu que FTP.
Sebastiaan 'CrashandDie' Lauwers wrote in message
<4691866d$0$21726$426a74cc@news.free.fr>:
SFTP, même si ça n'est que du scp
avec une coquille toute jolie autour
Ce n'est pas du tout le cas. SFTP est un protocole de manipulation de
fichiers distants tout à fait complet, et au passage largement mieux conçu
que FTP.
Sebastiaan 'CrashandDie' Lauwers wrote in message <4691866d$0$21726$:
SFTP, même si ça n'est que du scp avec une coquille toute jolie autour
Ce n'est pas du tout le cas. SFTP est un protocole de manipulation de fichiers distants tout à fait complet, et au passage largement mieux conçu que FTP.
Je pense que le plus simple resterait cependant de tout simplement se procurer un client capable de faire du SFTP
Si j'utilise FTP, c'est parce que le serveur n'accepte rien d'autre. (Heureusement, ça devient rare.)
octane
On 9 juil, 02:34, (Luc Habert) wrote:
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion ven ir de B, donc il va essayer de se connecter au port X de B, sur lequel il n' y a rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le client qui se croit connecté à A va essayer de se connecter au port X de A, et non de C.
et oui.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et no n un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
RFC 959: DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host address.
donc, si, l'adresse IP est bien envoyee. Et dans le temps, les gens s'en servait beaucoup pour faire ce qu'il s'appelle du fxp.
Le client ouvre une connection sur un serveur A, une connexion sur un serveur B. Sur le serveur A, il le met en attente de reception de fichier comme s'il fait un PUT, mais avec l'adresse IP de B. Sur B, il fait comme un GET, mais comme si l'IP¨etait celle de A. Et hop, le fichier est transfere de A vers B sans passer par le client. Tres utile a l'epoque ou l'on avait des connexions modems 56k et qu'il fallait deplacer des fichiers de giga d'un serveur ftp a l'autre.
On 9 juil, 02:34, Luc.Habert.00__a...@normalesup.org (Luc Habert)
wrote:
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine
locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au
serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion ven ir
de B, donc il va essayer de se connecter au port X de B, sur lequel il n' y a
rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le
client qui se croit connecté à A va essayer de se connecter au port X de A,
et non de C.
et oui.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le
protocole ftp, c'est seulement un numéro de port qui est envoyé et no n un
couple (IP,port), mais la deuxième possibilité me parait nettement
improbable.
RFC 959:
DATA PORT (PORT)
The argument is a HOST-PORT specification for the data
port
to be used in data connection. There are defaults for
both
the user and server data ports, and under normal
circumstances this command and its reply are not needed.
If
this command is used, the argument is the concatenation of
a
32-bit internet host address and a 16-bit TCP port
address.
This address information is broken into 8-bit fields and
the
value of each field is transmitted as a decimal number (in
character string representation). The fields are
separated
by commas. A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host
address.
donc, si, l'adresse IP est bien envoyee. Et dans le temps, les
gens s'en servait beaucoup pour faire ce qu'il s'appelle du fxp.
Le client ouvre une connection sur un serveur A, une
connexion sur un serveur B.
Sur le serveur A, il le met en attente de reception de fichier
comme s'il fait un PUT, mais avec l'adresse IP de B.
Sur B, il fait comme un GET, mais comme si l'IP¨etait celle
de A.
Et hop, le fichier est transfere de A vers B sans passer par le
client.
Tres utile a l'epoque ou l'on avait des connexions modems 56k
et qu'il fallait deplacer des fichiers de giga d'un serveur ftp
a l'autre.
Je pense plutôt que ça ne va simplement pas marcher. Soit A la machine locale, B l'intermédiaire, et C la distante.
Si tu fais du ftp actif, le client ftp sur A ouvre un port X en disant au serveur de s'y connecter. Sauf que le serveur sur C a vu la connexion ven ir de B, donc il va essayer de se connecter au port X de B, sur lequel il n' y a rien, ou alors un truc qui n'a rien à voir.
Si tu fais du ftp passif, c'est le serveur qui ouvre un port X, mais le client qui se croit connecté à A va essayer de se connecter au port X de A, et non de C.
et oui.
Enfin c'est ce que me soufle mon pipotron. Il faudrait voir si dans le protocole ftp, c'est seulement un numéro de port qui est envoyé et no n un couple (IP,port), mais la deuxième possibilité me parait nettement improbable.
RFC 959: DATA PORT (PORT)
The argument is a HOST-PORT specification for the data port to be used in data connection. There are defaults for both the user and server data ports, and under normal circumstances this command and its reply are not needed. If this command is used, the argument is the concatenation of a 32-bit internet host address and a 16-bit TCP port address. This address information is broken into 8-bit fields and the value of each field is transmitted as a decimal number (in character string representation). The fields are separated by commas. A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host address.
donc, si, l'adresse IP est bien envoyee. Et dans le temps, les gens s'en servait beaucoup pour faire ce qu'il s'appelle du fxp.
Le client ouvre une connection sur un serveur A, une connexion sur un serveur B. Sur le serveur A, il le met en attente de reception de fichier comme s'il fait un PUT, mais avec l'adresse IP de B. Sur B, il fait comme un GET, mais comme si l'IP¨etait celle de A. Et hop, le fichier est transfere de A vers B sans passer par le client. Tres utile a l'epoque ou l'on avait des connexions modems 56k et qu'il fallait deplacer des fichiers de giga d'un serveur ftp a l'autre.
