L'authentification par clé SSH échoue

30

J'essaye de ssh dans un serveur CentOS sur lequel je n'ai aucun contrôle .. l'administrateur a ajouté ma clé publique au serveur et insiste sur le fait que la faute réside en moi mais je ne peux pas comprendre ce qui ne va pas.

Config .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Autorisation sur mes fichiers clés:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Journal de connexion dont je ne peux pas comprendre le sens:

tim@tim-UX31A:~$ ssh -vvv [email protected]
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug3: order_hostkeyalgs: prefer hostkeyalgs: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,[email protected],[email protected],[email protected],aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).
ssh sshd ssh-keys Tim
la source
Des couvercles, il semble que la clé soit envoyée, mais aucune réponse n'est jamais reçue. -Êtes-vous censé vous connecter en tant que root, ou vous connectez-vous en tant que tim, puis utilisez sudo? Parfois, la connexion ssh en tant que root est désactivée. -Quelles sont les autorisations du répertoire .ssh lui-même? -Avez-vous le bon serveur? Le DNS se résout-il correctement? -Vous pouvez recréer les clés, puis utiliser ssh-copy-id pour copier manuellement la nouvelle clé publique dans le fichier authorized_keys. Juste au cas où la clé serait corrompue.
Kyle H
Merci d'avoir essayé d'aider! les autorisations sur mon dossier .ssh sont: drwx ------ 2 tim tim 4096 Okt 20 22:13 .ssh. La connexion en tant que root est correcte - cela a fonctionné il y a quelques semaines avant de reformater mon ordinateur. L'administrateur dit qu'il a ajouté les nouvelles clés correctement, mais je ne sais vraiment pas comment cela pourrait être de ma faute à ce stade
Tim
Comme l'a mentionné @KyleH, avez-vous essayé avec ssh [email protected]comme le journal mentionne Kerberos, le serveur CentOS pourrait être intégré au domaine (AD, IPA, ...). Vous devez savoir quel utilisateur vous êtes censé utiliser. Demandez à l'administrateur. Par exemple, nous utilisons IPA afin de permettre aux utilisateurs de se connecter à certains serveurs avec leur compte de domaine IPA et leur paire de clés et, si nécessaire, ils peuvent sudo. Pas d'accès root :)
Zina

Réponses:

18

Cela résout généralement la plupart des problèmes d'autorisation de clé autorisés SSH côté serveur , en supposant que quelqu'un n'a pas apporté de modifications supplémentaires aux autorisations.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Si votre administrateur a créé le fichier .ssh / ou .ssh / authorized_keys en tant que root (ce qui est le plus souvent le cas), alors le fichier appartenant à un autre utilisateur (même si root!) N'est pas autorisé.

Userify (clause de non-responsabilité: co-fondateur) procède automatiquement exactement de la même manière. Https://github.com/userify/shim/blob/master/shim.py#L285

Jamieson Becker
la source
Si tel était le problème, le client n'aurait pas essayé d'envoyer la clé au serveur en premier lieu; le journal donné dans la question est explicite.
Charles Duffy
Cela corrige le problème côté serveur. Vous avez raison de dire que le côté client est correct.
Jamieson Becker
1
Cela a finalement résolu mon problème. J'ai passé des heures à essayer de comprendre pourquoi mes clés publiques / privées n'étaient pas acceptées.
Daniel Harris
Un autre utilisateur a suggéré d' sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Réconomiser du temps de frappe, mais pourrait être plus difficile à comprendre pour un débutant
Jamieson Becker
11

J'ai eu exactement le même problème sur deux serveurs: un Linux exécutant un tronçon Debian et sur un NAS (Synology DS715)

il s'est avéré que dans les deux cas, les autorisations du répertoire personnel sur le serveur étaient incorrectes

l'auth.log sur le serveur a été très utile

Authentication refused: bad ownership or modes for directory /home/cyril

sous Linux, le bit d'écriture / groupe était activé (drwxrwxr - x), j'ai donc dû supprimer au moins le groupe d'écriture (chmod gw ~ /), puis cela a fonctionné

sur la Synology, pour une raison quelconque, il y avait un morceau collant

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Je devais le changer avec

chmod -t ~/

et je pourrais alors me connecter sans mot de passe

Cyril Chaboisseau
la source
Merci pour ça chmod -t... Je me suis retrouvé avec:admin@SYN:~$ ls -ald . .ssh .ssh/* drwxr-xr-x 6 admin users 4096 Jan 10 15:54 . drwx------ 2 admin users 4096 Jan 10 15:54 .ssh -rwx------ 1 admin users 401 Jan 10 15:54 .ssh/authorized_keys -rw------- 1 admin users 1679 Jan 10 15:49 .ssh/id_rsa -rwxr--r-- 1 admin users 396 Jan 10 15:49 .ssh/id_rsa.pub -rwx------ 1 admin users 396 Jan 10 10:04 .ssh/known_hosts
Stéphane
6

Lorsque vous utilisez CentOS 7, et je suis convaincu qu'il s'applique également aux autres systèmes d'exploitation Linux utilisant sshd. Avec l'accès root, vous pouvez en savoir plus sur les raisons de l'échec de l'authentification. Pour faire ça:

  1. Activez la journalisation pour sshd: vi /etc/ssh/sshd_config
  2. Sous enregistrement décommentation:

SyslogFacility AUTH LogLevel INFO

  1. Changer LogLevel INFO en LogLevel DEBUG
  2. Sauvegarder et quitter
  3. Redémarrez sshd systemctl restart sshd
  4. Regardez le fichier des messages tail -l /var/log/messages
  5. En utilisant un autre terminal, essayez de vous connecter avec ssh
  6. Tenter de se connecter avec ssh
  7. Consultez le journal d'authentification pour la cause exacte

Par exemple, je rencontrais certains des mêmes problèmes que ceux mentionnés ci-dessus. 

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

En utilisant ces étapes, j'ai pu confirmer que le problème était des autorisations sur le fichier authorized_keys. En définissant chmod sur 644 sur le fichier de clés autorisées de mon utilisateur, le problème a été résolu.

JonCav
la source
4

Il semble que les autorisations sur votre .sshdossier n'aient pas été copiées + collées correctement. Pourriez-vous l'ajouter à nouveau?

Si le mode strict est activé, nous devons nous assurer que .sshles autorisations sont correctes:

  • .ssh/ devrait avoir des perms 0700/rwx------
  • .ssh/*.pub les fichiers doivent être 644/rw-r--r--
  • .ssh/* (autres fichiers en .ssh) 0600/rw-------

À quoi les choses vous ressemblent-elles en termes de permission?

Kyle H
la source
Les autorisations sur mon dossier de départ (tim) sont de 755 (drwxr-xr-x) et les autorisations sur le dossier .ssh lui-même sont de 700 (drwx). id_rsa est 600 et le fichier .pub est 644 ..: / merci encore, j'espère que l'info aide
Tim
J'ai ssh travaillant sur de nombreux serveurs. Mon répertoire personnel est drwxr-xr-x (0755), .ssh est rwx ------ (0700), à l'intérieur .ssh ma clé de pub est -rw-r - r-- (0644), et le reste dans ce dossier sont -rw ------- (0600). Donc, vos autorisations sont bonnes et cela devrait passer la vérification stricte de l'hôte. Que contient votre fichier / etc / ssh_config? Quelque chose dans ~ / .ssh / config? J'ai eu la création de clé ssh pour une raison ou une autre ne fonctionne pas même s'il n'y a pas eu d'erreurs. Pouvez-vous essayer d'utiliser ssh-keygen pour régénérer vos clés, ssh-copy-id pour copier votre clé de pub sur le serveur distant sur lequel l'authentification par mot de passe est activée?
Kyle H
Malheureusement, je n'ai pas accès au serveur mais j'essaierai d'obtenir l'administrateur pour copier à nouveau ma clé de pub sur le serveur lundi. J'ai copié le contenu des fichiers de configuration dans pastebin: pastebin.com/eEaVMcvt - merci encore pour votre Aidez-moi!
Tim
Je vous en prie. Je suis heureux de vous aider! J'aime aussi la résolution de problèmes et surtout aider les autres avec Linux. Il y a une ligne impaire dans votre ssh-config qui pourrait causer des problèmes là où elle se trouve. Qu'est-ce que l'IP 10.0.12.28?
Kyle H
@KyleH a raison .. c'est presque certainement le problème. J'ai ajouté une autre réponse qui montre comment le réparer avec un accès root. Si vous contrôlez votre homedir, vous pouvez éventuellement le réparer vous-même, mais bien sûr, vous devez pouvoir vous connecter :)
Jamieson Becker
4

Juste au cas où quelqu'un tomberait sur cette réponse - aucune des recommandations n'a fonctionné dans mon scénario. Au final, le problème était que j'avais créé un compte sans mot de passe. Une fois que j'ai défini le mot de passe en utilisant usermod -p "my password" usernamepuis déverrouillé de force le compte, usermod -U usernametout était pêche.

Nathan Crause
la source
Votre réponse m'a signalé mon cas différent, mais aussi lié à l'utilisateur, lorsque j'essayais de me connecter lorsque le répertoire personnel que j'avais donné était plus imbriqué que celui avec lequel je me connectais ... Super d'avoir corrigé, merci!
Brett Zamir
2

J'ai eu un problème similaire , où la connexion ssh essaie la clé ~/.ssh/id_rsaavant de s'arrêter de façon inattendue:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

Dans mon cas, cela était dû à un ancien fichier de clé publique qui traînait dans le .sshrépertoire:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Le déplacement / la suppression id_rsa.pubdu .sshrépertoire a résolu le problème.

D'après ce que je comprends: lorsqu'une clé publique est présente côté client, SSH 1st valide la clé privée par rapport à celle-ci. S'il échoue, il n'essaiera pas d'utiliser la clé privée pour se connecter à distance.

J'ai envoyé un e-mail à la liste de diffusion openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Elouan Keryell-Even
la source
Ouaaahhhh. SÉRIEUSEMENT! Je n'aurais jamais regardé ça. openssh-8.0p1-5.fc30.x86_64btw. J'ai eu la clé publique du serveur précédent avec le même nom que le nouveau qui traîne fedora@(baloo).sshkey.pub, qui va avec fedora@(baloo).sshkeypassé sur la ligne de commande avec l' -ioption. L'authentification a échoué avec la nouvelle clé de serveur trouvée dans la nouvelle fedora@(baloo).sshkey- une clé RSA.
David Tonhofer
2

Nous avons rencontré ce problème. Les autorisations et la propriété des fichiers .ssh étaient toutes correctes. Dans / var / log / messages, nous avons trouvé:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO, la solution pour les développeurs vm où nous ne nous soucions pas de la sécurité est de désactiver selinux. Modifiez / etc / sysconfig / selinux et changez SELINUX = désactivé et redémarrez.

gaoithe
la source
2

Juste au cas où cela sauverait aussi quelqu'un. J'essayais de copier une clé de ma machine Ubuntu 18.04 sur 2 serveurs CentOS 7. J'avais l'habitude ssh-copy-idde les transférer. L'un a fonctionné, l'autre non. J'ai donc parcouru toutes les autorisations de débogage et je n'ai rien trouvé. J'ai finalement récupéré le fichier /etc/ssh/sshd_configsur les deux serveurs et je les ai parcourus ligne par ligne. Finalement, je l'ai trouvé, probablement quelque chose que quelqu'un a modifié bien avant de commencer.

Une lecture: AuthorizedKeysFile .ssh/authorized_keys

Et une autre lecture:, AuthorizedKeysFile ~/.ssh/authorized_keysqui était sur le serveur qui n'acceptait pas mes clés. Évidemment, en regardant entre les deux fichiers et en notant le commentaire qui indique que les modèles de recherche par défaut n'incluent pas le début, ~/je l'ai supprimé et redémarré sshd. Problème résolu.

Aaron Chamberlain
la source
1

A également rencontré ce problème. setroubleshoot ne semble pas fonctionner dans mon environnement, il n'y a donc pas d'enregistrement de ce type dans / var / log / messages. Désactiver SELinux n'était pas une option pour moi, donc je l'ai fait

restorecon -Rv ~/.ssh

Après cette connexion, la clé rsa a bien fonctionné.

lapin_
la source
1

La raison dans mon cas était une option définie AuthorizedKeysFiledans le fichier /etc/ssh/sshd_config. Il était défini sur le /home/webmaster/.ssh/authorized_keysrépertoire personnel d'un autre utilisateur ( ), donc l'utilisateur auquel j'essayais de me connecter n'avait pas accès à ce fichier / répertoire.

Après l'avoir changé et redémarré ssh-server ( service ssh restart), tout est revenu à la normale. Je peux me connecter avec ma clé privée maintenant.

ihoru
la source
1

Dans notre cas, les problèmes étaient liés au fait que nos règles de pare-feu et de NAT n'étaient pas correctement configurées.

le port 22, était dirigé vers le serveur incorrect où nos clés et notre utilisateur n'étaient pas reconnus.

Si quelqu'un arrive à ce point. tcpdump et telnet peuvent être vos amis

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Vous remarquerez que ces deux serveurs ont des versions openssh différentes. Cela m'a aidé à repérer le problème assez rapidement. Si vos hôtes utilisent les mêmes versions ssh, vous devrez essayer de faire une trace compressée sur la destination pour voir si le trafic arrive réellement à la destination.

Ssh peut générer beaucoup de trafic, ce qui rend tcpdump difficile à trouver ce que vous recherchez.

Cela m'a aidé

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Essayez de telnet à partir d'un 3 serveur différent et non de votre ordinateur actuel @ [mylocalip]. Vous voulez voir quel trafic atteint réellement votre serveur.

nelaaro
la source
0

Un journal des erreurs côté client se terminant comme ceci:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]'s password:

peut être provoqué par une restriction côté serveur (distante) sur la connexion root lorsque le fichier de configuration sshd contient:

PermitRootLogin: no

La suggestion de JonCav pour activer la journalisation a été utile pour déboguer un tel problème. Bien que le débogage côté client ait été remarquablement inutile, le placement des éléments suivants dans le fichier sshd_config du serveur sshd :

SyslogFacility AUTH
LogLevel DEBUG

a fini par produire des messages de journal utiles:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

Dans le cas où seule la connexion root échoue et à condition que l'utilisation de l'authentification par clé uniquement pour la connexion root soit autorisée par votre politique de sécurité, une modification du fichier sshd_config peut aider:

 PermitRootLogin without-password

Votre kilométrage peut varier, bien que cela aide souvent, une autre configuration peut toujours interférer selon un commentaire trouvé dans certains fichiers sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Même si vous ne pouvez pas facilement modifier la configuration du serveur distant pour déboguer de cette manière, on peut éprouver la configuration côté client dans une certaine mesure en utilisant les mêmes fichiers d'identité pour ssh vers un compte non root sur le même serveur distant.

kbulgrien
la source
0

Je peux voir pourquoi la sécurité peut déranger les gens. J'ai juste eu lessh won't use my key nouveau problème. Je l'ai résolu en me connectant au serveur distant et en exécutant

/usr/sbin/sshd -sDp 23456

puis à partir de mon bureau (en essayant de ssh vers le serveur)

ssh -vvvv server -p 23456

Sur le serveur, j'ai Authentication refused: bad ownership or modes for directory /

Un nouveau sysadmin avait gâché la permission et la propriété, que j'ai corrigée avec:

chmod 0755 / ; chown root:root /

(Je suis habitué à avoir besoin chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubmais sshd vérifiant / trouvant les autorisations root est un nouveau pour moi.) Maintenant, je vais vérifier un rootkit, puis essuyer et réinstaller de toute façon.

Alexx Roche
la source
0

Dans mon cas, les problèmes étaient liés à l'exécution incorrecte du shell.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Fichier / etc / passwd modifié pour cet utilisateur

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....
nelaaro
la source
0

J'ai eu ce problème sur CentOS 7. Je suis un utilisateur Linux régulier basé sur Debian, j'étais donc un poisson hors de l'eau. J'ai remarqué que dans certains serveurs, cela fonctionnait et dans un seul, cela ne fonctionnait pas. L'audit.log n'a rien dit d'utile et le secure.log n'a rien donné non plus. J'ai trouvé que la seule vraie différence était quelques différences de contexte de sécurité sur les fichiers et les répertoires entre ceux qui fonctionnaient et ceux qui ne fonctionnaient pas. Obtenez la sécurité avec

sudo ls -laZ <user-home>/.ssh

du répertoire (je suppose que beaucoup de valeurs par défaut sur sshd_config).

Vous devriez en voir ssh_home_tetuser_home_t attributs . Si vous ne le faites pas, utilisez la chconcommande pour ajouter les attributs manquants.

Par exemple

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Dans mon cas, je soupçonne que l'utilisateur a été créé de manière non standard. Sa maison était un répertoire/var/lib .

Plus d'informations sur: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

hanzo2001
la source