Utilisation d'otp avec ssh

Bonjour,

je rencontre quelques problèmes pour mettre en place un OTP sur ssh. Pour un debian sur arm.

Voila les logiciels que j'utilise :
- Openssh 6.0p1
- Openssl 0.9.8k
- PAM utilisé conjointement avec OTPW librairy.

D'après la documentation je dois mettre ma configuration dans le fichier :
/etc/pam.conf

ou dans le répertoire (de mémoire)

/etc/pam/

J'ai choisi la première option (est-ce que cela peut avoir une influence négative ? )

Et voici le contenu du fichier /etc/pam.conf :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

# # The PAM configuration file for the `login' service # login auth requisite pam_securetty.so login auth required pam_nologin.so login auth sufficent pam_unix.so login auth required pam_unix.so login auth optional pam_group.so login account requisite pam_time.so login account required pam_unix.so login password required pam_cracklib.so retry=3 login password required pam_unix.so shadow md5 use_authtok login session required pam_unix.so   # # The PAM configuration file for the `sshd' service # sshd auth required pam_otpw.so sshd session optional pam_otpw.so

---

Et la configuration (les points qui d'après ce que j'ai trouvé sont important) de sshd dans /etc/sshd_config:

Code:

---

1 2 3 4

ChallengeResponseAuthentication yes PasswordAuthentication no UsePrivilegeSeparation no UsePAM yes

---

Quand j'essaye de me connecter via ssh, j'ai toujours le login standard, il ne prend pas en compte l'OTP...

Quelqu'un à déjà mis un tel système en place ?

Merci de votre aide.

J'ai refait une série de tests, et toujours pas de résultats, mais j'ai eu des comportements surprenant :

Lorsque je démarre /sbin/sshd, j'ai l'impression qu'il ne prend pas ma configuration en compte.

Par exemple si je change le port d'écoute en 25 à la place de 22, je ne peux pas joindre le port 25 via ssh et il me donne un avertissement comme quoi il y a eu trop d'essais de connexions infructueux. Par contre le port 22 est toujours accessible.

Par contre si j'ajoute une erreur dans la configuration, il ne veux pas s'exécuter donc il lit bien ma configuration mais ne la prend pas en compte.

Pam ou OTPW remplace-t-il la configuration par défaut de sshd ?

Merci

tu relances pas sshd comme ça tu le relance que le bin pas le chargement des params.
faut le faire dans l'init avec son script d'init.

après pour le reste je sais pas trop, mais pam ou autre ne remplace pas sshd ça sert juste de couche authentification

D'accord merci pour l'information. Pourtant si je relance sshd en lançant le binaire, il accède bien au fichier de configuration vu qu'il voit une erreur de syntaxe lorsqu'il y en a une.

Citation:

---

Envoyé par manticore

D'accord merci pour l'information. Pourtant si je relance sshd en lançant le binaire, il accède bien au fichier de configuration vu qu'il voit une erreur de syntaxe lorsqu'il y en a une.

---

pas forcément, c'est pas parce qu'il check les syntaxes, qu'il recharge les variables etc...

Oui tu as raison, il faisait juste un check de syntaxe.

J'ai pu avancé un peu, et faire des tests supplémentaire grâce à strace.

Donc il charge bien ma configuration. J'ai mis la configuration minimum que l'on voit dans les tutoriaux :

Code:

---

1 2	auth required pam_otpw.so session optional pam_otpw.so

---

Code:

---

1 2 3 4

ChallengeResponseAuthentication yes PasswordAuthentication no UsePrivilegeSeparation no UsePAM yes

---

Maintenant il me donne le message (sans me demander d'authentification) :

Citation:

---

Permission denied (publickey,keyboard-interactive).

---

J'ai ensuite enlever l'authentification par publickey dans sshd, afin d'avoir que le keyboard-interactive.

Est-ce correcte ? L’authentification via le pam-otpw.so doit-elle se faire par "keyboard-interactive" ?

Merci

p.s. On doit placer le fichier .otpw dans le home de l'user j'ai mis le mien dans /root/.otpw
Et je me connecte avec root@[IP].

EDIT :

Je trouve aussi une erreur dans le strace, apres le chargement de ma configuration, il essaye d'accéder à /dev/log mais n'y arrive pas.

Voici l'extrait :

Citation:

---

stat64("/bin/bash", {st_mode=S_IFREG|0755, st_size=702896, ...}) = 0
[pid 635] stat64("/etc/pam.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid 635] open("/etc/pam.d/sshd", O_RDONLY|O_LARGEFILE) = 4
[pid 635] fstat64(4, {st_mode=S_IFREG|0644, st_size=99, ...}) = 0
[pid 635] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0
[pid 635] read(4, "ChallengeResponseAuthentication "..., 4096) = 99
[pid 635] gettimeofday({1345726846, 400988}, NULL) = 0
[pid 635] open("/etc/localtime", O_RDONLY) = 6
[pid 635] fstat64(6, {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
[pid 635] fstat64(6, {st_mode=S_IFREG|0644, st_size=1892, ...}) = 0
[pid 635] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0
[pid 635] read(6, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\2
[pid 635] _llseek(6, -28, [1864], SEEK_CUR) = 0
[pid 635] read(6, "\nCET-1CEST,M3.5.0,M10.5.0/3\n", 4096) = 28
[pid 635] close(6) = 0
[pid 635] munmap(0x4001e000, 4096) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0
[pid 635] gettimeofday({1345726846, 443436}, NULL) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0
[pid 635] gettimeofday({1345726846, 455977}, NULL) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0
[pid 635] gettimeofday({1345726846, 468582}, NULL) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0
[pid 635] gettimeofday({1345726846, 481394}, NULL) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0
[pid 635] gettimeofday({1345726846, 493878}, NULL) = 0
[pid 635] socket(PF_FILE, 0x80002 /* SOCK_??? */, 0) = 6
[pid 635] connect(6, {sa_family=AF_FILE, path="/dev/log"}, 110) = -1 ECONNREF)
[pid 635] close(6) = 0

---

J'ai refait des tests, sur une station Ubuntu 10.04, et ça marche avec une configuration semblable, à celle que j'ai mise sur mon debian, par contre de base ubuntu à créé pas mal de fichier en plus, j'ai essayé de les ajouter sur debian, mais aucun résultat.

Voila la liste des fichiers :

Citation:

---

-rw-r--r-- 1 root root 1.2K Aug 23 16:31 common-account
-rw-r--r-- 1 root root 1.3K Aug 23 16:31 common-auth
-rw-r--r-- 1 root root 1.5K Aug 23 16:31 common-password
-rw-r--r-- 1 root root 1.5K Aug 23 16:31 common-session
-rw-r--r-- 1 root root 1.5K Aug 23 16:31 common-session-noninteractive
-rw-r--r-- 1 root root 520 Aug 23 16:44 other
-rw-r--r-- 1 root root 56 Aug 23 16:52 sshd

---

Il y a un paramètre dont je n'ai pas pu trouvé la correspondance pour debian

Citation:

---

#

# As of pam 1.0.1-6, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure sha512
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_gnome_keyring.so
# end of pam-auth-update config

---

Je ne sais pas comment modifier la ligne du password optional pam_gnome_keyring.so pour debian.

J'ai enfin trouvé le problème, il venait de la cross-compilation, le binaire ne contenait pas grand chose finalement.

La configuration n'était donc pas en cause.