Est-ce que quelqu'un a déjà fait la manip consistant à remplacer le
ssh "de base" fourni avec Tiger par le openssh de DP ?
Je me lancerai bien dans le truc car j'ai besoin d'un ssh compilé avec
les TCP-Wrappers (ce qui n'est pas le cas du ssh de base, me
semble-t-il). Mébon... ssh étant la seule porte d'entrée de mon
bouzin, j'ai pas non plus envie de tout péter.
--
Eric Jacoboni, ne il y a 1441491720 secondes
Je peux utiliser les deux (sur deux ports différents), mais en pratique, je n'utilise que celui de DP (sur le port 2222), car plus récent (4.*).
Ah merci, je me lance, alors
-- Eric Jacoboni, ne il y a 1441495093 secondes
Vincent Lefevre
Dans l'article , Eric Jacoboni écrit:
Vincent Lefevre <vincent+ writes:
Je peux utiliser les deux (sur deux ports différents), mais en pratique, je n'utilise que celui de DP (sur le port 2222), car plus récent (4.*).
Ah merci, je me lance, alors
En fait, je pense que c'est parce que l'OpenSSH d'Apple utilise LaunchDaemons et que l'OpenSSH de DP utilise StartupItems qu'il n'y a pas de clash.
Quand je l'avais installé, la mise en place des groupes buggait. J'avais dû changer des groupes de admin à wheel dans le répertoire /Library/StartupItems/OpenSSH.
D'autre part, pour l'activer au boot, il faut mettre OPENSSH=-YES- dans le fichier "/etc/hostconfig".
Dans l'article <m2hd7uy4e8.fsf@titine.jacoboni.fr>,
Eric Jacoboni <jaco@neottia.net> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
Je peux utiliser les deux (sur deux ports différents), mais en pratique,
je n'utilise que celui de DP (sur le port 2222), car plus récent (4.*).
Ah merci, je me lance, alors
En fait, je pense que c'est parce que l'OpenSSH d'Apple utilise
LaunchDaemons et que l'OpenSSH de DP utilise StartupItems qu'il
n'y a pas de clash.
Quand je l'avais installé, la mise en place des groupes buggait.
J'avais dû changer des groupes de admin à wheel dans le répertoire
/Library/StartupItems/OpenSSH.
D'autre part, pour l'activer au boot, il faut mettre OPENSSH=-YES-
dans le fichier "/etc/hostconfig".
Je peux utiliser les deux (sur deux ports différents), mais en pratique, je n'utilise que celui de DP (sur le port 2222), car plus récent (4.*).
Ah merci, je me lance, alors
En fait, je pense que c'est parce que l'OpenSSH d'Apple utilise LaunchDaemons et que l'OpenSSH de DP utilise StartupItems qu'il n'y a pas de clash.
Quand je l'avais installé, la mise en place des groupes buggait. J'avais dû changer des groupes de admin à wheel dans le répertoire /Library/StartupItems/OpenSSH.
D'autre part, pour l'activer au boot, il faut mettre OPENSSH=-YES- dans le fichier "/etc/hostconfig".
Oui, c'est bien avec -vvv que je lance ssh, mais je ne voulais pas polluer avec des lignes de debug... en gros, il arrive à l'authentification par mot de passe, me donne trois essais et me jette.
debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password 's password: (...) debug3: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,password,keyboard-interactive).
Il faut peut-être décommenter les lignes
SyslogFacility AUTH LogLevel INFO
Non, rien, aucun log, ni nouveau ni dans ceux existants
ou rapporter un bug sur le bugzilla d'OpenDarwin (si tu n'arrives pas à résoudre avec le -vvv).
C'est ce que je vais finir par faire, mais je voudrais être sûr que ce n'est pas moi qui merdoie dans l'installation avant (sur un FBSD, ça m'a pris 10mn pour faire tourner le bouzin, donc j'imagine que c'est encore les trucs àlc de l'admin Apple qui posent problème). Une install par défaut de ssh qui ne permet pas une connexion par mot de passe (pas sur le compte root, évidemment) et qui ne logge rien, ça me semble un peu curieux quand même
Vérifie que dans LaunchDaemons, le propriétaire est bien root et le groupe est bien wheel.
Vivi, tout est bon.
-- Eric Jacoboni, ne il y a 1441540450 secondes
Vincent Lefevre <vincent+news@vinc17.org> writes:
Essaie avec un -vvv.
Oui, c'est bien avec -vvv que je lance ssh, mais je ne voulais pas
polluer avec des lignes de debug... en gros, il arrive à
l'authentification par mot de passe, me donne trois essais et me
jette.
debug2: we did not send a packet, disable method
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: userauth_kbdint: disable: no info_req_seen
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
jaco@titine.jacoboni.fr's password:
(...)
debug3: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
Il faut peut-être décommenter les lignes
SyslogFacility AUTH
LogLevel INFO
Non, rien, aucun log, ni nouveau ni dans ceux existants
ou rapporter un bug sur le bugzilla d'OpenDarwin (si tu n'arrives pas
à résoudre avec le -vvv).
C'est ce que je vais finir par faire, mais je voudrais être sûr que ce
n'est pas moi qui merdoie dans l'installation avant (sur un FBSD, ça
m'a pris 10mn pour faire tourner le bouzin, donc j'imagine que c'est
encore les trucs àlc de l'admin Apple qui posent problème). Une
install par défaut de ssh qui ne permet pas une connexion par mot de
passe (pas sur le compte root, évidemment) et qui ne logge rien, ça me
semble un peu curieux quand même
Vérifie que dans LaunchDaemons, le propriétaire est bien root et
le groupe est bien wheel.
Oui, c'est bien avec -vvv que je lance ssh, mais je ne voulais pas polluer avec des lignes de debug... en gros, il arrive à l'authentification par mot de passe, me donne trois essais et me jette.
debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug2: we sent a keyboard-interactive packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password 's password: (...) debug3: packet_send2: adding 64 (len 56 padlen 8 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentications that can continue: publickey,password,keyboard-interactive debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,password,keyboard-interactive).
Il faut peut-être décommenter les lignes
SyslogFacility AUTH LogLevel INFO
Non, rien, aucun log, ni nouveau ni dans ceux existants
ou rapporter un bug sur le bugzilla d'OpenDarwin (si tu n'arrives pas à résoudre avec le -vvv).
C'est ce que je vais finir par faire, mais je voudrais être sûr que ce n'est pas moi qui merdoie dans l'installation avant (sur un FBSD, ça m'a pris 10mn pour faire tourner le bouzin, donc j'imagine que c'est encore les trucs àlc de l'admin Apple qui posent problème). Une install par défaut de ssh qui ne permet pas une connexion par mot de passe (pas sur le compte root, évidemment) et qui ne logge rien, ça me semble un peu curieux quand même
Vérifie que dans LaunchDaemons, le propriétaire est bien root et le groupe est bien wheel.
Vivi, tout est bon.
-- Eric Jacoboni, ne il y a 1441540450 secondes
Vincent Lefevre
Dans l'article , Eric Jacoboni écrit:
Il faut peut-être décommenter les lignes
SyslogFacility AUTH LogLevel INFO
Non, rien, aucun log, ni nouveau ni dans ceux existants
Je n'ai pas de logs non plus, apparemment (ni dans /var/log, ni dans /Library/Logs, ni dans ~/Library/Logs).
Sous Linux, les logs de sshd se trouvent dans /var/log/auth.log, et /etc/syslog.conf contient la ligne:
auth,authpriv.* /var/log/auth.log
Il faut probablement modifier le /etc/syslog.conf; sous Mac OS X, j'ai:
authpriv.*;remoteauth.crit /var/log/secure.log
Il faut peut être ajouter auth...
En revanche, je n'ai aucune idée pour le mot de passe refusé (je crois que c'est pareil pour moi, mais je ne me connecte que par authentification par clé publique).
Dans l'article <m2wtgpj3d5.fsf@titine.jacoboni.fr>,
Eric Jacoboni <jaco@neottia.net> écrit:
Il faut peut-être décommenter les lignes
SyslogFacility AUTH
LogLevel INFO
Non, rien, aucun log, ni nouveau ni dans ceux existants
Je n'ai pas de logs non plus, apparemment (ni dans /var/log, ni
dans /Library/Logs, ni dans ~/Library/Logs).
Sous Linux, les logs de sshd se trouvent dans /var/log/auth.log, et
/etc/syslog.conf contient la ligne:
auth,authpriv.* /var/log/auth.log
Il faut probablement modifier le /etc/syslog.conf; sous Mac OS X,
j'ai:
authpriv.*;remoteauth.crit /var/log/secure.log
Il faut peut être ajouter auth...
En revanche, je n'ai aucune idée pour le mot de passe refusé (je
crois que c'est pareil pour moi, mais je ne me connecte que par
authentification par clé publique).
Non, rien, aucun log, ni nouveau ni dans ceux existants
Je n'ai pas de logs non plus, apparemment (ni dans /var/log, ni dans /Library/Logs, ni dans ~/Library/Logs).
Sous Linux, les logs de sshd se trouvent dans /var/log/auth.log, et /etc/syslog.conf contient la ligne:
auth,authpriv.* /var/log/auth.log
Il faut probablement modifier le /etc/syslog.conf; sous Mac OS X, j'ai:
authpriv.*;remoteauth.crit /var/log/secure.log
Il faut peut être ajouter auth...
En revanche, je n'ai aucune idée pour le mot de passe refusé (je crois que c'est pareil pour moi, mais je ne me connecte que par authentification par clé publique).
