lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce
dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout
est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification,
sans continuer si l'identité est valide?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Vincent Bernat
OoO En ce milieu de nuit étoilée du jeudi 03 août 2006, vers 04:44, Olivier Croquette disait:
Bonjour, lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
Cependant, le code de retour ne va pas t'aider car ce sera toujours -1. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En ce milieu de nuit étoilée du jeudi 03 août 2006, vers 04:44,
Olivier Croquette <ocroquette@ocroquette.free.fr> disait:
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce
dernier vérifie l'identité du serveur, et avorte si elle échoue. Si
tout est OK, le client SSH continue (demande de mot de passe ou
autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification,
sans continuer si l'identité est valide?
Cependant, le code de retour ne va pas t'aider car ce sera toujours -1.
--
panic("IRQ, you lose...");
2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
OoO En ce milieu de nuit étoilée du jeudi 03 août 2006, vers 04:44, Olivier Croquette disait:
Bonjour, lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
Cependant, le code de retour ne va pas t'aider car ce sera toujours -1. -- panic("IRQ, you lose..."); 2.2.16 /usr/src/linux/arch/mips/sgi/kernel/indy_int.c
Julien Salgado
Olivier Croquette a écrit(wrote):
Bonjour,
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
En effet, on peut utiliser ssh-keyscan, le man de la version de OpenSSH contient un bon exemple.
-- Julien
Olivier Croquette a écrit(wrote):
Bonjour,
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce
dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout
est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification,
sans continuer si l'identité est valide?
En effet, on peut utiliser ssh-keyscan, le man de la version de OpenSSH
contient un bon exemple.
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
En effet, on peut utiliser ssh-keyscan, le man de la version de OpenSSH contient un bon exemple.
-- Julien
patpro ~ patrick proniewski
In article <eaqsm6$euh$03$, Olivier Croquette wrote:
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
man ssh-keyscan
patpro
-- http://www.patpro.net/
In article <eaqsm6$euh$03$1@news.t-online.com>,
Olivier Croquette <ocroquette@ocroquette.free.fr> wrote:
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce
dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout
est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification,
sans continuer si l'identité est valide?
In article <eaqsm6$euh$03$, Olivier Croquette wrote:
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
man ssh-keyscan
patpro
-- http://www.patpro.net/
Guillaume
Olivier Croquette a wroté :
Bonjour,
Bonjour,
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce
dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout
est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification,
sans continuer si l'identité est valide?
lorsqu'on se connecte sur une machine en utilisant (Open-)SSH, ce dernier vérifie l'identité du serveur, et avorte si elle échoue. Si tout est OK, le client SSH continue (demande de mot de passe ou autre).
Question: existe-t'il un moyen de réaliser uniquement la vérification, sans continuer si l'identité est valide?
4.3. How do I administer SSH after I have the daemon running?
The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with RSA host authentication, the server needs to know the client's public key.
You can collect these automatically each night using either make-ssh-known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://ftp.cs.hut.fi/ssh/contrib/.
Thomas König has written a script to process output from one of these utilities, check for new keys, warn about hosts which have changed their keys (which could be an indication of a man in the middle attack) and generate a complete new file. This script is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.
With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable)
4.3. How do I administer SSH after I have the daemon running?
The central problem of administering ssh is the management of host keys.
To allow a client to connect to a remote host with RSA host
authentication, the server needs to know the client's public key.
You can collect these automatically each night using either
make-ssh-known-hosts.pl (distributed with the ssh source distribution)
or with the much faster ssh-keyscan, from ftp://ftp.cs.hut.fi/ssh/contrib/.
Thomas König has written a script to process output from one of these
utilities, check for new keys, warn about hosts which have changed their
keys (which could be an indication of a man in the middle attack) and
generate a complete new file. This script is available from
http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.
With these utilities, you can write scripts to verify public keys on a
regular basis. When new machines are running ssh or people have changed
public keys, you may want to contact the people in question directly, to
make sure there were no man in the middle attacks (to which these
utilities are vulnerable)
4.3. How do I administer SSH after I have the daemon running?
The central problem of administering ssh is the management of host keys. To allow a client to connect to a remote host with RSA host authentication, the server needs to know the client's public key.
You can collect these automatically each night using either make-ssh-known-hosts.pl (distributed with the ssh source distribution) or with the much faster ssh-keyscan, from ftp://ftp.cs.hut.fi/ssh/contrib/.
Thomas König has written a script to process output from one of these utilities, check for new keys, warn about hosts which have changed their keys (which could be an indication of a man in the middle attack) and generate a complete new file. This script is available from http://www.uni-karlsruhe.de/~ig25/ssh-faq/comp-host-list.
With these utilities, you can write scripts to verify public keys on a regular basis. When new machines are running ssh or people have changed public keys, you may want to contact the people in question directly, to make sure there were no man in the middle attacks (to which these utilities are vulnerable)
