Forum Linux.mandriva Probleme SSH

Posté par  .
Étiquettes : aucune
0
29
août
2006
Bonjour,
Je possede un serveur sous Mandriva 2006 et je prend controle dessus sous WindowsXP a l'aide de Putty, pour le moment juste avec le login et le password de l'utilisateur, j'aimerai utiliser le systeme clés publique/privé mais je rencontre un probleme, voici tout d'abord ma config:
sshd_conf:
# $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

#Port 22
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 192.168.0.1
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key


# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

#RSAAuthentication yes
PubkeyAuthentication yes

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication mechanism.
# Depending on your PAM configuration, this may bypass the setting of
# PasswordAuthentication, PermitEmptyPasswords, and
# "PermitRootLogin without-password". If you just want the PAM account and
# session checks to run without PAM authentication, then enable this but set
# ChallengeResponseAuthentication=no
UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
Compression yes
IgnoreUserKnownHosts no
PrintMotd yes
StrictModes yes
RSAAuthentication yes
PermitEmptyPasswords no
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10

# no default banner path
#Banner /some/path

# override default of no subsystems
#Subsystem sftp /usr/lib/ssh/sftp-server

-Pour passer en cles public/privé je passe "PasswordAuthentication" à no

-j'ai generé ma cles public/privé grace a puttygen j'ai donc copié la clés dans /home/(mon utilisateur)/.ssh/authorized_keys

-j'ai relancé le service sshd

-quand je lance la connexion avec puttyagent en chargeant ma cles privé, la fenetre s'ouvre en demandant un login et des que je met l'utilisateur, la fenetre se ferme et plu rien..

Avez vous une idée?
Merci d'avance à tt le monde
  • # clés serveur

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    # HostKey for protocol version 1
    #HostKey /etc/ssh/ssh_host_key
    # HostKeys for protocol version 2
    #HostKey /etc/ssh/ssh_host_rsa_key


    Pas de clés sur le serveur!

    Lire par exemple http://www.trustonme.net/didactels/111.html et la page man sshd_config

    Protocol 2

    Ta clé faite sur puty est ssh2?

    La gelée de coings est une chose à ne pas avaler de travers.

    • [^] # Re: clés serveur

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Oups!

      Pas de clés sur le serveur!

      Je voulais dire

      Pas de clés sur le serveur?

      Vérifies qu'elle y soient.

      La gelée de coings est une chose à ne pas avaler de travers.

      • [^] # Re: clés serveur

        Posté par  . Évalué à 3.

        Bonjour,

        Il faut également faire attention à quelques points importants :
        - putty génère une paire de clé (clé privée/clé publique) dont le format n'est pas compatible avec OpenSSH. Sur le serveur OpenSSH, il faut copier la clé publique telle qu'elle apparaît dans la fenêtre de puttygen, pas celle contenue dans un éventuel fichier créé sur le disque (dans le fichier authorized_keys, la clé publique doit être sur une seule ligne).
        - Sur le serveur, le répertoire HOME de l'utilisateur sous lequel tu te connectes ne doit être accessible en écriture que pour le propriétaire.
        - Le répertoire $HOME/.ssh ne doit être accessible en lecture qu'au propriétaire.

        Enfin, puttyagent ne permet pas de se connecter à un serveur SSH : pour cela il faut utiliser putty. puttyagent permet simplement de ne pas avoir à taper la passphrase protégeant la clé privée à chaque utilisation : au lancement de puttyagent, les clés privées sont chargées, les passphrases correspondantes demandées et ces clés sont ensuite servies à Putty lorsque cela est nécessaire.

        Dans putty, il faut ouvrir la session en indiquant le fichier contenant la clé privée (dans Connection/SSH/Auth) : si tu ne l'as pas fait, putty ne tient pas compte de cette clé privée et la connexion de peut se faire puisque tu as, de plus, désactivé l'authentification par mot de passe.

        J'espère que la réponse à tes questions se trouve dans les éléments indiqués.

        A+
        JJD

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.