Forum Linux.débutant Accès SSH sur Fedora 18 XFCE 32 bits

Posté par astuces-info.biz le 15 février 2013 à 22:29. Licence CC By‑SA.

Étiquettes :

-1

fév.

2013

J'essaye de configurer un accès SSH

Sur le serveur voici mon fichier /etc/ssh/sshd_config :

AuthorizedKeysFile /home/jo/.ssh/authorized_keys2
AuthorizedKeysFile /root/.ssh/authorized_keys2
HostKey /root/.ssh/id_rsa
Port 22
ListenAddress 192.168.0.3
LogLevel DEBUG3
PasswordAuthentication yes
PermitRootLogin yes
Protocol 2
PrintMotd yes
PubkeyAuthentication yes
PermitEmptyPasswords no
PidFile /var/run/sshd.pid

Quand je copie la clé en mode verbose depuis le client qui est sur la même distribution que moi (sur le client je n'ai pas touché aux fichiers de configuration) cela me dit que le mot de passe n'est pas bon pourtant je suis sur que j'ai tapé le bon voici ce que cela me donne :

[jo@localhost .ssh]$ scp -v id_rsa.pub jo@90.24.212.231:/home/jo/.ssh/
Executing: program /usr/bin/ssh host 90.24.212.231, user jo, command scp -v -t /home/jo/.ssh/
OpenSSH_6.1p1, OpenSSL 1.0.1c-fips 10 May 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 50: Applying options forFeb 15 22:05:39 localhost sshd[1660]: Set /proc/self/oom_score_adj to 0
Feb 15 22:05:39 localhost sshd[1660]: Connection from 78.250.190.247 port 30018
Feb 15 22:05:42 localhost sshd[1660]: Failed publickey for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:46 localhost sshd[1660]: error: Could not get shadow information for jo
Feb 15 22:05:46 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:51 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:56 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:57 localhost sshd[1660]: Connection closed by 78.250.190.247 [preauth]
*
debug1: Connecting to 90.24.212.231 [90.24.212.231] port 22.
debug1: Connection established.
debug1: identity file /home/jo/.ssh/id_rsa type 1
debug1: identity file /home/jo/.ssh/id_rsa-cert type -1
debug1: identity file /home/jo/.ssh/id_dsa type -1
debug1: identity file /home/jo/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 87:38:3a:e6:a2:86:db:da:47:57:49:47:93:96:62:89
debug1: Host '90.24.212.231' is known and matches the RSA host key.
debug1: Found key in /home/jo/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/jo/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /home/jo/.ssh/id_dsa
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
jo@90.24.212.231's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
jo@90.24.212.231's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
Permission denied, please try again.
jo@90.24.212.231's password:
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
lost connection

Voici les logs du serveur :

Feb 15 22:05:39 localhost sshd[1660]: Set /proc/self/oom_score_adj to 0
Feb 15 22:05:39 localhost sshd[1660]: Connection from 78.250.190.247 port 30018
Feb 15 22:05:42 localhost sshd[1660]: Failed publickey for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:46 localhost sshd[1660]: error: Could not get shadow information for jo
Feb 15 22:05:46 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:51 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:56 localhost sshd[1660]: Failed password for jo from 78.250.190.247 port 30018 ssh2
Feb 15 22:05:57 localhost sshd[1660]: Connection closed by 78.250.190.247 [preauth]

J'ai redirigé le port 22 de mon routeur vers l'IP locale de mon serveur et j'ai désactiver le firewall coté client et coté serveur

Qui as une idée du problème ?

# bizarre cette ligne ?!

Posté par nono14 (site web personnel) le 16 février 2013 à 10:18. Évalué à 2.
```
Feb 15 22:05:46 localhost sshd[1660]: error: Could not get shadow information for jo
```
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# utiliser les bons outils

Posté par NeoX le 16 février 2013 à 10:22. Évalué à 2.

depuis l'utilisateur qui a la clé à copier

ssh-copy-id jo@90.24.212.231

avec le mot de passe de jo, ca doit marcher.

sinon comme dit dans le post precedent,

Feb 15 22:05:46 localhost sshd[1660]: error: Could not get shadow information for jo

on dirait que l'utilisateur jo n'existe pas sur ton serveur (ou en tout cas n'a pas de ligne dans /etc/shadow qui stocke les mots de passe
# Réponse

Posté par astuces-info.biz le 17 février 2013 à 13:54. Évalué à -1.

L'utilisateur existe bien et il a bel et bien une ligne dans le fichier /etc/shadow
Pour tous vous dire à l'installtion du serveur j'ai spécifier le mot de passe root, on m'a demander de créer un utilisateur j'ai mis "jo" comme nom et je lui ai assigné un mot de passe.

Si mon chevalier en or sur un beau cheval blanc pouvait arriver pour m'aider je serais heureux comme tout :D
# Réponse

Posté par astuces-info.biz le 17 février 2013 à 14:07. Évalué à -1.

même avec l'utilitaire ssh-copy-id c'est pareil
# autre test

Posté par matthieu bollot (site web personnel, Mastodon) le 17 février 2013 à 14:36. Évalué à 2.

vu que tu as autorisé la connexion en root, tu peux essayer un ssh root@90.24.212.231 ?

Au moins ça montrera que tu peux te connecter en ssh et que le problème se situe plus au niveau du user plutôt que de ssh
- [^] # Re: autre test
  
  Posté par astuces-info.biz le 18 février 2013 à 01:06. Évalué à -1.
  
  J'avais oublié de dire avec root c'est pareil cela ne fonctionne pas.
  
  Qui a une idée ?
  - [^] # Re: autre test
    
    Posté par matthieu bollot (site web personnel, Mastodon) le 18 février 2013 à 09:51. Évalué à 2.
    
    il est possible que SE linux (installé par défaut sur fedora) bloque l'accès à /etc/shadow
    regarde si tu peux le désactiver ou autoriser l'accès pour ssh (je sais pas exactement où c'est)
# Fichier de config?

Posté par apkwa le 18 février 2013 à 10:58. Évalué à 1.
Personnellement, le fichier de config me pique les yeux. Notamment le "HostKey /root/.ssh/id_rsa". La clé privée de root pour l'hôte? A priori pourquoi pas mais bon. Et puis vérifier les droits sur ce fichier, car comme le dit le man sshd_config:
```
     HostKey
             Spécifie un fichier contenant une clef privée de machine utilisée
             par SSH.  Par défaut /etc/ssh/ssh_host_key pour la version 1 du
             protocole, et /etc/ssh/ssh_host_rsa_key et
             /etc/ssh/ssh_host_dsa_key pour la version 2 du protocole. Note :
             sshd refuse d’utiliser un fichier accessible au groupe ou aux
             autres.  On peut avoir plusieurs fichiers de clef de machine.
             Les clefs « rsa1 » sont utilisées pour la version 1 du protocole,
             et les clefs « dsa » ou « rsa » sont utilisées pour la version 1
             du protocole SSH.
```
- [^] # réponse
  
  Posté par astuces-info.biz le 18 février 2013 à 22:59. Évalué à -1.
  
  J'ai désactiver selinux côté client ainsi que côté serveur j'ai rebooter les deux.
  
  Quand je fais scp /home/jo/.ssh/id_rsa.pub jo@192.168.0.3:/home/jo/.ssh ça me dit "scp commande not found" pourtant scp est bien installé côté client ,j'ai supprimé le package "openssh-server" sur le client en tapant la commande "yum erase openssh-server"
  
  Par contre côté client en tapant ssh-copy-id jo@192.168.0.3 cela fonctionne le fichier authrized_keys sur le serveur est crée.
  
  Donc bon quelque bizzareries encore puis je ne trouve pas les logs de openssh (et non pas openssh-server) donc côté client dans le fichier /var/log/messages
  
  Si certaines personnent s'y connaissent et veulent bien me faire partager leur connaissances je suis ok mais en tout cas le cela fonctionne.
  
  Merci de votre aide je pense que la solution était bien de désactiver selinux sur le client et le serveur (je sais pas lequel des deux à fait effet si c'est l'un ou l'autre ou les deux)
  
  Je l'ai fais en éditant le fichier /etc/selinux/config et en mettant "disabled" à "SELINUX="
  
  Merci à vous longue vie au forum !!
  
  Aller voir mon site http://astuces-info.biz/astuces-info.html et http://astuces-info.biz/drupal7
  - [^] # Re: réponse
    
    Posté par nono14 (site web personnel) le 19 février 2013 à 09:25. Évalué à 2.
    
    ça me dit "scp commande not found"
    
    Impossible!
    
    Valeur du PATH?
    Find, locate, which, type ,…
    
    Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# Avec la configuration par défaut ?

Posté par Nils Ratusznik (site web personnel, Mastodon) le 20 février 2013 à 12:40. Évalué à 1.

Par défaut sur une Fedora, ce que tu cherches à faire ne pose aucun problème particulier (même pas besoin de désactiver SELinux ou le firewall). Comme j'ai pu lire, le fichier de configuration OpenSSH me semble aussi assez mal fichu.

Plusieurs possibilités s'offrent à toi :
- réinstaller la distribution (réflexe windowsien, certes…)
- réinstaller les configurations par défaut d'OpenSSH si tu les as quelque part
- supprimer tes configurations personnalisées et désinstaller puis réinstaller OpenSSH (qui te recréera la config par défaut)

Je vais détailler la dernière possibilité, puis la création de clé SSH.

D'abord sauver les configurations :
[root@lolcathost ~]# tar -cvzpf /root/ssh_backup.tgz /etc/ssh/
Puis sauvegarde des clés :
[jo@lolcathost ~]$ tar -cvzpf /home/jo/ssh_old_keys.tgz /home/jo/.ssh/
Ensuite, on fait le ménage par le vide :
[root@lolcathost ~]# rm -rf /etc/ssh/ /home/jo/.ssh/ [root@lolcathost ~]# yum -y remove openssh openssh-server openssh-clients openssh-askpass
Après, on réinstalle :
[root@lolcathost ~]# yum -y install openssh openssh-server openssh-clients openssh-askpass
On s'assure que les fichiers ont été générés (ça s'affiche peut-être durant l'installation, mais dans le doute…) :
[root@lolcathost ~]# ls /etc/ssh/ moduli sshd_config ssh_host_dsa_key.pub ssh_host_key.pub ssh_host_rsa_key.pub ssh_config ssh_host_dsa_key ssh_host_key ssh_host_rsa_key
On s'assure que les outils clients sont là :
[root@lolcathost ~]# which ssh ssh-copy-id /bin/ssh /bin/ssh-copy-id
On s'assure que sshd est lancé :
[root@lolcathost ~]# systemctl status sshd.service
Si ce n'est pas le cas, lancer sshd et l'activer par défaut :
[root@lolcathost ~]# systemctl start sshd.service
[root@lolcathost ~]# systemctl enable sshd.service
A partir de maintenant, on peut commencer à regarder si la connexion fonctionne avec un mot de passe :
[userb@machinedistante ~]$ ssh jo@adresseippubliquedelolcathost
Depuis la machine distante, on peut générer la clé publique avec par exemple la commande suivante :
[userb@machinedistante ~]$ ssh-keygen -t rsa -b 4096
Je laisse le soin à d'autres de débattre sur le fait de mettre ou non une phrase de passe.
Ensuite, toujours depuis la machine distante, on utilise ssh-copy-id (fourni par le paquet openssh-clients, voir plus haut pour l'installation) pour copier proprement la clé publique :
[userb@machinedistante ~]$ ssh-copy-id jo@adresseippubliquedelolcathost
Enfin, une nouvelle connexion ssh pour vérifier que la clé est présente :
[userb@machinedistante ~]$ ssh jo@adresseippubliquedelolcathost "cat ~/.ssh/authorized_keys"

Bon, j'espère avoir tout couvert. Si tu n'as pas touché la configuration du firewall et de SELinux, tu devrais pourvoir ensuite les réactiver sans problème.
- [^] # Re: Avec la configuration par défaut ?
  
  Posté par astuces-info.biz le 19 mars 2013 à 17:06. Évalué à -1.
  
  C'est bon pour le SSH tout marche par contre stopper puis désactiver selinux et le firewall est souvent obligatoire pour moi.
  Je vais essayer de mettre en place le sftp sa risque de pas être facile non plus !
  
  https://astuces-info.no-ip.biz
  
  PS : que pensez vous du certificat (auto-signé) ?

Suivre le flux des commentaires

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