Le mardi 06 octobre 2009 à 14:30 +0200, François TOURDE a écrit :
> Le 14523ième jour après Epoch,
> jul...@nura.eu écrivait:
>
> > Donc :
> > - avec une clé publique de type ssh-rsa --> tout le monde peut se
> > connecter
>
> Tout le monde, ou juste ton client?
Plusieurs clients (6) que je gè
Le 14523ième jour après Epoch,
jul...@nura.eu écrivait:
> Donc :
> - avec une clé publique de type ssh-rsa --> tout le monde peut se
> connecter
Tout le monde, ou juste ton client?
Virer les fichiers rsa peut ne pas suffire. As-tu un agent ssh qui
tourne, et qui serait l'émetteur de l'accrédit
Le mardi 06 octobre 2009 à 14:02 +0200, Benjamin MENUET a écrit :
> Tu peux aussi faire un test en virant le authorized_keys et regarde
> dans les logs pour voir comment ça régit.
En virant authorized_keys (sur le serveur) plus de connextion
automatique.
Avec un fichier authorized_keys vide : pas
Le mardi 06 octobre 2009 à 13:57 +0200, giggzounet a écrit :
> Julien a écrit :
> > Voilà la sortie de ssh -v à partie du client :
> >
> > debug1: Host '' is known and matches the RSA host key.
> > debug1: Found key in /root/.ssh/known_hosts:11
> > debug1: ssh_rsa_verify: signature correct
>
Tu peux aussi faire un test en virant le authorized_keys et regarde dans les
logs pour voir comment ça régit.
Le 6 octobre 2009 13:57, giggzounet a écrit :
> Julien a écrit :
> > Voilà la sortie de ssh -v à partie du client :
> >
> > OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
> > debug1:
Le mardi 06 octobre 2009 à 12:53 +0200, Nicolas KOWALSKI a écrit :
> Bonjour,
>
> Julien writes:
>
> > Ce qui me gène c'est que tout le monde peut s'y connecter même sans
> > fichier id_dsa.pub et id_dsa dans ~/.ssh sur le client !
>
> C'est peut-être juste le RhostsRSAAuthentication qui est en
Voilà la sortie de ssh -v à partie du client :
OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to [xx.xxx.xx.x] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
J'ai changé le loglevel vers DEBUG2, redémarrer sshd (sur le serveur)
Sur le client j'ai supprimé les clé dans .ssh (rm -f ~/.ssh/id*)
voilà un extrait des log auth.log sur le serveur :
debug2: user_key_allowed: check options: 'ssh-dss B3...
debug2: key_type_from_name: unknown key type '
Le mardi 6 octobre 2009 13:34, Julien a écrit :
> Le mardi 06 octobre 2009 à 12:13 +0200, Alain Vaugham a écrit :
> > Le mardi 6 octobre 2009 09:55, Julien a écrit :
> > > PermitRootLogin yes
> >
> > Ce ne serait pas à éviter?
>
> oui mais les utilisateurs veulent ce connecter en root donc ...
...
Le mardi 06 octobre 2009 à 12:13 +0200, Alain Vaugham a écrit :
> Le mardi 6 octobre 2009 09:55, Julien a écrit :
>
> > PermitRootLogin yes
> Ce ne serait pas à éviter?
oui mais les utilisateurs veulent ce connecter en root donc ...
> --
> Alain Vaugham
> Clef GPG : 0xD26D18BC
>
--
Lisez la
Alain Vaugham a écrit :
> Le mardi 6 octobre 2009 12:37, Jean-Yves F. Barbier a écrit :
>> Alain Vaugham a écrit :
>>> Le mardi 6 octobre 2009 09:55, Julien a écrit :
PermitRootLogin yes
>>> Ce ne serait pas à éviter?
>> Pourquoi?
>
> Parceque Julien se connecte en root :
> Il a écrit :
>
>
Bonjour,
Julien writes:
> Ce qui me gène c'est que tout le monde peut s'y connecter même sans
> fichier id_dsa.pub et id_dsa dans ~/.ssh sur le client !
C'est peut-être juste le RhostsRSAAuthentication qui est en
fonctionnement ? A désactiver dans /etc/ssh/sshd_config.
--
Nicolas
--
Lisez l
Le mardi 6 octobre 2009 12:37, Jean-Yves F. Barbier a écrit :
> Alain Vaugham a écrit :
> > Le mardi 6 octobre 2009 09:55, Julien a écrit :
> >> PermitRootLogin yes
> >
> > Ce ne serait pas à éviter?
>
> Pourquoi?
Parceque Julien se connecte en root :
Il a écrit :
>Depuis le serveur A :
>
># ssh
Julien a écrit :
> Le mardi 06 octobre 2009 à 11:43 +0200, Yves Rutschle a écrit :
>> On Tue, Oct 06, 2009 at 09:55:37AM +0200, Julien wrote:
>>> ce dernier serveur peut se
>>> connecter en SSH au ancien serveur
>> Un serveur qui se connecte à un serveur? Il y a un problème
>> dans l'énoncé du suje
Alain Vaugham a écrit :
> Le mardi 6 octobre 2009 09:55, Julien a écrit :
>
>> PermitRootLogin yes
> Ce ne serait pas à éviter?
Pourquoi?
Si l'attaquant arrive à compromettre un compte std, il-y-a des chances
pour qu'il ait les connaissances nécessaires pour obtenir les droits
de root: la protec
Le mardi 6 octobre 2009 09:55, Julien a écrit :
> PermitRootLogin yes
Ce ne serait pas à éviter?
--
Alain Vaugham
Clef GPG : 0xD26D18BC
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists Vous pouvez aussi ajouter le mot
``spam'' dans vos champs "Fro
Le mardi 06 octobre 2009 à 11:43 +0200, Yves Rutschle a écrit :
> On Tue, Oct 06, 2009 at 09:55:37AM +0200, Julien wrote:
> > ce dernier serveur peut se
> > connecter en SSH au ancien serveur
>
> Un serveur qui se connecte à un serveur? Il y a un problème
> dans l'énoncé du sujet.
Une de mes mach
Le mardi 06 octobre 2009 à 11:53 +0200, Benjamin MENUET a écrit :
> Bonjour,
>
> Est-ce que ton nouveau serveur est nouveau dans ton architecture, ou
> est-ce qu'il remplace un ancien serveur ?
>
> S'il remplace un ancien serveur, qu'il as le même nom et que tu as
> copié ta conf ssh c'est possibl
Bonjour,
Est-ce que ton nouveau serveur est nouveau dans ton architecture, ou est-ce
qu'il remplace un ancien serveur ?
S'il remplace un ancien serveur, qu'il as le même nom et que tu as copié ta
conf ssh c'est possible.
Vérifie sur ton client ta clé publique rsa ou dsa suivant celle que tu
util
19 matches
Mail list logo
