Public Cloud OVHcloud - Clefs ssh pour un utilisateur lambda
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

Clefs ssh pour un utilisateur lambda

Von
DavidG28
Erstellungsdatum 2019-03-11 10:10:23 (edited on 2024-09-04 12:44:32) in Public Cloud OVHcloud

Hello à tous,

j'essaye désespérément de créer un accès SSH via une clef à mon dev sur mon instance public cloud, il n'aurait pas les droits root.
J'ai l'impression que le seul moyen de créer un accès SSH via une clef est d'ajouter cette clef sur l'interface OVH.
Cependant, on ne peut pas attribuer la clef à un utilisateur, il aurait les droits root.

Comment faire ?

Merci


3 Antworten ( Latest reply on 2019-03-12 17:36:22 Von
Jean RAVE aka Greenhoster
)

C'est un besoin ponctuel ou vous souhaitez l'automatiser à la création de l'instance?

Si c'est ponctuel :

* Créez l'utilisateur
* Créez une paire de clefs via `ssh-keygen` avec cet utilisateur.

```text > Cependant, on ne peut pas attribuer la clef à un utilisateur, il aurait les droits root.


crée un user
dans `/home/user/.ssh/authorized_keys`: ajouter la clé

si c'est pour un dev, demande lui s'il dev sur une plateforme git (gitlab, framagit, github)
dans l'affirmative, voilà une astuce:
```text
su pseudo
mkdir -p .ssh

curl -s https://framagit.org/pseudo.keys >> .ssh/authorized_keys
curl -s https://gitlab.com/pseudo.keys >> .ssh/authorized_keys
curl -s https://github.com/pseudo.keys >> .ssh/authorized_keys

echo >> .ssh/authorized_keys
```
choisir la bonne plateforme
ne pas faire ça en root
Bitbucket je n'ai pas essayé ```


ssh-keygen


merci pour vos réponses.
Mais il n'y a rien à faire, quelque soit la méthode que j'utilise j'ai : "Server refused our key"
Alors que cela marchait très bien sur mon serveur dédié ...

C'est que vous n'avez pas utilisé la clef publique générée.
Regardez dans les logs, vous aurez plus d'informations sur le soucis.

Probablement `/var/log/auth.log`.

un `ssh -v login@serveur` est utile pour voir ce qui se passe côté client

Je n'ai rien de particulier ici, j'ai même fait un tail -f lors d'une tentative de connexion, il ne s'est rien passé.
Pour résumer ce que j'ai fait :
- ssh-keygen avec le user concerné
- la public key je l'ai copié dans /home/{nom user}/.ssh/authorized_keys
- la private je l'ai copié en local sur un fichier windows "key.ppk"
- j'ai pris soin d'avoir les droits 600 sur authorized_keys et 700 sur .ssh/ pour l'utilisateur
- sur Putty j'ai chargé le fichier key.ppk
- à la connexion j'ai mis le user en question en login
et là j'ai le message "Server refused our key" ...

voici ce que j'ai en ligne de commande, sachant que j'utilise putty habituellement pour me connecter :

debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to el [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/david/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/david/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u6
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u6 pat OpenSSH* compat 0x04000000
debug1: Authenticating to el:22 as 'david'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:qwPLSNtPHES2ygQJwpm+7uyvG2fy+mtg480EvmP500Q
The authenticity of host 'el (127.0.1.1)' can't be established.
ECDSA key fingerprint is SHA256:qwPLSNtPHES2ygQJwpm+7uyvG2fy+mtg480EvmP500Q.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'el' (ECDSA) to the list of known hosts.
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/david/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/david/.ssh/id_dsa
debug1: Trying private key: /home/david/.ssh/id_ecdsa
debug1: Trying private key: /home/david/.ssh/id_ed25519
debug1: Next authentication method: password

> tail -f lors d'une tentative de connexion, il ne s'est rien passé.

c'est que tu n'atteins pas le serveur...

> Connecting to el [127.0.1.1] port 22.

tu te connectes à local host?


Server refused our key


Ok j'ai trouvé mon problème.
D'une part le format de la clef ssh-keygen était en openSSH, il fallait convertir avec Puttygen.
D'autre part à chaque fois que je copiais collé la première lettre se barrait, je ne sais pas pourquoi ....

Merci en tout cas

Bonsoir,

Si je peux me permettre, la clé ssh doit-être généré par le dev lui même avec une passphrase.
Ensuite le dev te donne la partie publique pour que tu la déploie sur ton serveur.

Je précise ça, car la clé va le responsabiliser et clairement l'identifier lors de connexion au serveur.
Celle-ci lui appartient et à lui seul, pour des raisons de sécurité, on n'échange pas les clés privées.

Sinon la procédure ne change pas, et on peut le faire via puttygen

Bon courage
https://www.captainadmin.com