Accès SSH par clef RSA

Support Debian
#1

Bonsoir,
Je voudrais instaurer l’authentification par clef RSA pour le ssh et peut-être même davantage quand le premier fonctionnera.
J’ai lu la doc de Debian qui dit de mettre la clef dans ~/user/.ssh/authorized_keys ce que j’ai fait.
J’ai vérifié les paramètres de /etc/ssh/sshd_config tout est ok.

Je redémarre ssh et même sshd car j’ai peur que ce ne soit pas considéré comme service identique.
Mais quoi qu’il arrive mon serveur refuse ma clef.

En fouillant je vois écrit qu’il faut une clef in one line ? C’est quoi ?
Faut-il que la clef tienne sur uine seule ligne ? Car mon logiciel Puttygen la sort sur plusieurs lignes. Du coup j’ai tenté de modifié ma clef en supprimant les retours à la ligne mais en vain.

Ensuite j’ai vu qu’il fallait que la clef publique commence par ssh-rsa or avec Puttygen ça commence par :

---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20150611" AAAcharabia ---- END SSH2 PUBLIC KEY ----

Peut-on la modifier à la main pour faire commencer par ssh-rsa ? Si oui comment ? Si non comment obtenir une bonne clef publique que Openssh sache reconnaître ? Si possible reconnu par kitty et WinSCP ?

#2

J’ai fait cela il y a presqu’un an alors j’ai un peu oublié mais j’avais noté précisément ce que j’avais fait :

Pour pouvoir faire du SSH ou copier des fichiers d’une machine A vers une machine B, sans fournir le mot de passe root de la machine B :
Sur la machine A (en l’occurence le serveur), sous root, créer un fichier contenant une clé privée et un fichier contenant une clé publique
par la commande ssh-keygen -t rsa (ne pas mettre de mot de passe).
Ces deux fichiers sont créés dans /root/.ssh, quelque soit le répertoire d’où on ait lancé la commande ssh-keygen et ont pour noms
id_rsa (clé privée) et id_rsa.pub (clé publique).
Il faut ensuite copier le fichier /root/.ssh/id_rsa.pub de la machine A sous le nom /root/.ssh/authorized_keys sur la machine B (en l’occurence les clients).
Le script suivant fait cela à condition d’avoir créé d’abord sur la machine A un répertoire .ssh contenant le fichier authorized_keys, dans le répertoire ou se trouve le script, (ce dernier répertoire .ssh n’a pas exactement le même contenu que /root/.ssh) :

   #!/bin/bash
   # Charge la clé rsa sur les clients pour pouvoir se connecter en root sur eux sans fournir le mot de passe 
   # Ce script doit etre lancé depuis un répertoire qui contient le .ssh dont on a besoin
   # Ce fichier .ssh ne peut être vu que par ls -a
   # Il faut être root sur la machine depuis laquelle on fait ça
   for adresse in 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 66 67 68 69 70 71
   do
      echo xxx.yyy.zzz.$adresse
      scp -r .ssh xxx.yyy.zzz.$adresse:/root/
      # Juste pour vérifier 
      slogin -l root xxx.yyy.zzz.$adresse 'echo $HOSTNAME'
   done

Ce script va donc copier la clé au bon endroit sur tous les PC d’adresses xxx.yyy.zzz.101, xxx.yyy.zzz.102, xxx.yyy.zzz.103, etc.

#3

Là je viens de planter le serveur du coup je suis entrain de le passer en mode rescue.
En attendant je pense avoir compris quelques erreur de ma part.
La première c’est que authorized_keys serait un fichier et non un répertoire. Je corrigerais ça quand je remettrai la main sur mon serveur. Merci de me confirmer ma pensée ça m’évitera de marracher des cheveux.
La seconde j’ai justement planté le serveur en ajoutant dans la config sshd_config le paramètre PreferredAuthetification publickey.

Du coup comme son nom ne l’indique pas c’est pas le mode d’authentification préféré mais le seul mode possible. Mais ça je l’apprends à mes dépens.
Sauriez-vous en combien de temps kimsufi installe le mode rescue ? J’attends leur mail de confirmation mais j’ai l’impression que ce n’est pas automatisé comme je pensais.

#4

bonsoir.

pour défricher un peu le terrain:

http://formation-debian.via.ecp.fr/ssh.html#idp8385744

http://www.octetmalin.net/linux/tutoriels/ssh-fichier-etc-sshd_config-configuration-machine-serveur.php

http://www.tldp.org/LDP/solrhe/Securing-Optimizing-Linux-RH-Edition-v1.3/chap15sec122.html

http://wiki.centos.org/HowTos/Network/SecuringSSH

et bien d’autres encore.

#5

Oui authorized_keys est bien un fichier.
C’est simplement le nom que doit porter le fichier id_rsa.pub sur la machine distante.
Je ne crois pas qu’il faille y modifier quoique ce soit à la main, oui il commence par ssh-rsa AAAAB3Nza … dans mon cas.

#6

Moi je lisais ce tuto debian.org/devel/passwordlessssh.fr.html
Je n’avais pas lu attentivement la phrase :
Ensuite, ajoutez le contenu du fichier de la clé publique indiqué ci-dessus à ~/.ssh/authorized_keys
Ce qui implique en effet que c’est un fichier et non un répertoire comme je faisais depuis le début.

Ensuite ma troisième erreur c’était de générer les cles RSA de mon PC Windows et ensuite je transférais sur le serveur or il vaut mieux faire l’inverse. Générer les clés sur le serveur et transférer la clé privée sur mon PC et ensuite la rendre compatible avec Puttygen.

J’ai hâte de mettre la main sur le mode rescue.

#7

[quote=“Karl_Abruti”]Oui authorized_keys est bien un fichier.
C’est simplement le nom que doit porter le fichier id_rsa.pub sur la machine distante.
Je ne crois pas qu’il faille y modifier quoique ce soit à la main, oui il commence par ssh-rsa AAAAB3Nza … dans mon cas.[/quote]

OK merci pour la confirmation qu’il s’agit bien d’un fichier.
Simplement le nom du fichier de ma clef publique pas son contenu ? Merci pour le détail.

Il n’y a rien à modifier quand on génère la clef sur Debian mais à partir d’un Windows ça fout le bazard. Mais j’ai pris le problème dans le bon sens ça fera un soucis en moins j’en ai déjà bien assez.

Je vais me coucher après tout je ne peux plus rien tester tant que le serveur est planté.

#8

Oui, selon mon expérience il y a juste à modifier le nom du fichier de la clef publique, il n’y a rien à modifier dans son contenu.

#9

[mono]$ ssh -v user@xxx.xxx.xxx.xxx[/mono] ?

#10

Euh … c’est quoi le but de cette commande en fait ?

J’ai pas l’impression que c’est ce qui va ajouter ma clef publique dans le serveur et la reconnaître.

J’ai utilisé

Ça fonctionne pour user présent dans /home.

Maintnenat j’aimerais bien y ajouter une clé publique mais pour root sauf que j’ai l’impression que ça ne fonctionne pas su root.
Sachant que pour le root je place le fichier dans /.ssh/authorized_keys mais c’est peut-être pas le bon endroit.

#11

Bon j’ai réussi pour root en fait il faut mettre le fichier dans /root/.ssh et non dans /.ssh

Persiste tout de même un dernier problème le but de cette manœuvre étant de désactiver le root login.
Sauf que quand je change la valeur de PermitRootLogin que ce soit en without-password ou no ça plante le serveur.

#12

Je vous montre /etc/ssh/sshd_config on ne sait jamais

[code]# Package generated configuration file

See the sshd_config(5) manpage for details

What ports, IPs and protocols we listen for

Port 22

Use these options to restrict which interfaces/protocols sshd will bind to

#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2

HostKeys for protocol version 2

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

Lifetime and size of ephemeral version 1 server key

KeyRegenerationInterval 3600
ServerKeyBits 1024

Logging

SyslogFacility AUTH
LogLevel VERBOSE

Authentication:

LoginGraceTime 600
PermitRootLogin no # C’est là que ça merde quand c’est sur no ou without-password. Sur yes le serveur reste accessible.
StrictModes no
#PreferredAuthentifications publickey
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

Don’t read the user’s ~/.rhosts and ~/.shosts files

IgnoreRhosts yes

For this to work you will also need host keys in /etc/ssh_known_hosts

RhostsRSAAuthentication no

similar for protocol version 2

HostbasedAuthentication no

Uncomment if you don’t trust ~/.ssh/known_hosts for RhostsRSAAuthentication

#IgnoreUserKnownHosts yes

To enable empty passwords, change to yes (NOT RECOMMENDED)

PermitEmptyPasswords no

Change to yes to enable challenge-response passwords (beware issues with

some PAM modules and threads)

ChallengeResponseAuthentication yes

Change to no to disable tunnelled clear text passwords

PasswordAuthentication yes

Kerberos options

#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

GSSAPI options

#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
Banner /etc/issue.net

Allow client to pass locale environment variables

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

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 and

PasswordAuthentication. Depending on your PAM configuration,

PAM authentication via ChallengeResponseAuthentication may bypass

the setting of “PermitRootLogin without-password”.

If you just want the PAM account and session checks to run without

PAM authentication, then enable this but set PasswordAuthentication

and ChallengeResponseAuthentication to ‘no’.

UsePAM yes
[/code]

#13

SSH est fait pour fonctionner en tant que simple utilisateur et il est souvent préconisé de ne pas autoriser l’accès “root”. Ton config est donc bon.

#14

[quote=“debuntu”]
[mono]AuthorizedKeysFile [strike]%h/[/strike].ssh/authorized_keys[/mono][/quote]
[mono]AuthorizedKeysFile /root/.ssh/authorized_keys[/mono]

#15

Alors ?

#16

?