Otentikasi SSH-Key gagal

30

Saya mencoba ssh ke server CentOS yang saya tidak punya kendali atas .. admin telah menambahkan kunci publik saya ke server dan menegaskan kesalahan terletak pada saya, tetapi saya tidak tahu apa yang salah.

Konfigurasi dalam .ssh:

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

Izin pada file-kunci saya:

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

Log koneksi yang saya tidak bisa mengerti:

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
sumber
Dari kelopaknya, sepertinya kunci dikirim, tetapi tidak ada respons yang diterima. -Apakah Anda seharusnya login sebagai root, atau apakah Anda login sebagai tim dan kemudian menggunakan sudo? Terkadang ssh login sebagai root dinonaktifkan. -Apa izin dari direktori .ssh itu sendiri? -Apakah Anda memiliki server yang tepat? Apakah dns menyelesaikan dengan benar? -Anda dapat membuat kunci lagi, dan kemudian menggunakan ssh-copy-id untuk secara manual menyalin kunci publik baru ke file official_keys. Untuk berjaga-jaga jika kuncinya rusak entah bagaimana.
Kyle H
Terima kasih telah mencoba membantu! izin pada folder .ssh saya adalah: drwx ------ 2 tim tim 4096 Okt 20 22:13 .ssh. Masuk sebagai root sudah benar - sebenarnya berfungsi beberapa minggu yang lalu sebelum saya memformat ulang komputer saya. Admin mengatakan dia telah menambahkan kunci baru dengan benar, tetapi saya benar-benar tidak tahu bagaimana ini bisa menjadi kesalahan saya
Tim
Seperti @KyleH sebutkan, pernahkah Anda mencobanya dengan ssh [email protected]log yang menyebutkan Kerberos server CentOS bisa menjadi Domain Terpadu (AD, IPA, ...). Anda harus mencari tahu pengguna apa yang seharusnya Anda gunakan. Tanyakan pada administrator. Kami misalnya menggunakan IPA sehingga kami memungkinkan pengguna untuk terhubung ke server tertentu dengan akun domain IPA mereka dan pasangan kunci dan jika perlu mereka dapat melakukan sudo. Tidak ada akses root :)
Zina

Jawaban:

18

Ini biasanya akan menyelesaikan sebagian besar masalah izin kunci resmi SSH di sisi server , dengan asumsi seseorang tidak membuat perubahan tambahan pada izin.

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

Jika admin Anda membuat file .ssh / direktori atau .ssh / Authorized_keys sebagai root (yang paling umum bagaimana ini dilakukan), maka memiliki file yang dimiliki oleh pengguna lain (bahkan jika root!) Tidak diperbolehkan.

Userify (disclaimer: co-founder) secara otomatis melakukan hal yang persis sama .. https://github.com/userify/shim/blob/master/shim.py#L285

Jamieson Becker
sumber
Jika ini masalahnya, klien tidak akan mencoba mengirim kunci ke server sejak awal; log yang diberikan dalam pertanyaan itu eksplisit.
Charles Duffy
Ini memperbaiki masalah sisi server. Anda benar bahwa sisi klien baik-baik saja.
Jamieson Becker
1
Ini akhirnya menyelesaikan masalah saya. Menghabiskan waktu berjam-jam untuk mencari tahu mengapa kunci publik / pribadi saya tidak diterima.
Daniel Harris
Pengguna lain menyarankan sudo chown $USER:$USER ~/ -R; sudo chmod o-rwx ~/ -Ryang akan menghemat waktu mengetik, tetapi mungkin lebih sulit bagi seorang pemula untuk mengerti
Jamieson Becker
11

Saya memiliki masalah yang sama persis pada dua server: Linux yang menjalankan Debian stretch dan pada NAS (Synology DS715)

ternyata dalam kedua kasus, izin direktori home di server salah

auth.log di server sangat membantu

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

di Linux, ia memiliki bit tulis / grup pada (drwxrwxr - x), jadi saya harus menghapus setidaknya tulisan pada grup (chmod gw ~ /) dan kemudian ia bekerja

pada Synology, untuk alasan apa pun, ada sedikit lengket

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

Saya harus mengubahnya dengan

chmod -t ~/

dan saya kemudian dapat terhubung tanpa kata sandi

Cyril Chaboisseau
sumber
Terima kasih untuk itu chmod -t... Saya berakhir dengan: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

Saat menggunakan CentOS 7, dan saya yakin berlaku untuk OS Linux lain yang menggunakan sshd juga. Dengan akses root, Anda dapat menentukan lebih lanjut tentang mengapa otentikasi mungkin gagal. Untuk melakukan ini:

  1. Aktifkan pencatatan untuk sshd: vi /etc/ssh/sshd_config
  2. Di bawah pembatalan komentar:

SyslogFacility AUTH LogLevel INFO

  1. Ubah INFO LogLevel ke LogLevel DEBUG
  2. Simpan dan keluar
  3. Mulai kembali sshd systemctl restart sshd
  4. Tonton file pesan tail -l /var/log/messages
  5. Menggunakan terminal lain, coba sambungkan dengan ssh
  6. Mencoba terhubung dengan ssh
  7. Tinjau log otentikasi untuk penyebab pastinya

Sebagai contoh, saya mengalami beberapa masalah yang sama seperti yang disebutkan di atas. 

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

Dengan menggunakan langkah-langkah ini saya dapat mengonfirmasi bahwa masalahnya adalah izin pada file yang diotorisasi. Dengan mengatur chmod ke 644 pada file kunci resmi pengguna saya, masalahnya telah diperbaiki.

JonCav
sumber
4

Sepertinya izin pada .sshfolder Anda tidak menyalin + menempel dengan benar. Bisakah Anda menambahkannya lagi?

Jika mode ketat diaktifkan maka kami harus memastikan .sshmemiliki izin yang benar dari:

  • .ssh/ harus memiliki perms 0700/rwx------
  • .ssh/*.pub file seharusnya 644/rw-r--r--
  • .ssh/* (file lain dalam .ssh) 0600/rw-------

Bagaimana hal-hal mencari Anda dari segi izin?

Kyle H
sumber
Izin pada folder rumah saya (tim) adalah 755 (drwxr-xr-x) dan izin pada folder .ssh itu sendiri adalah 700 (drwx). id_rsa adalah 600 dan file .pub adalah 644 ..: / terima kasih lagi, harap info ini membantu
Tim
Saya memiliki ssh yang berfungsi untuk banyak server. Direktori rumah saya adalah drwxr-xr-x (0755), .ssh adalah rwx ------ (0700), di dalam .ssh kunci pub saya adalah -rw-r - r-- (0644), dan sisanya dalam folder itu adalah -rw ------- (0600). Jadi, izin Anda baik dan harus melewati pemeriksaan Host Ketat. Apa yang ada di file / etc / ssh_config Anda? Apa saja di ~ / .ssh / config? Saya memiliki kreasi kunci ssh karena satu dan lain alasan tidak berfungsi meskipun tidak ada kesalahan. Bisakah Anda mencoba menggunakan ssh-keygen untuk meregenerasi kunci Anda, ssh-copy-id untuk menyalin kunci pub Anda ke server jarak jauh yang telah mengaktifkan otentikasi kata sandi?
Kyle H
Sayangnya saya tidak memiliki akses ke server tetapi saya akan mencoba untuk mendapatkan admin untuk menyalin kunci pub saya ke server lagi pada hari Senin .. Saya menyalin isi file konfigurasi ke pastebin: pastebin.com/eEaVMcvt - terima kasih lagi untuk Anda Tolong!
Tim
Sama-sama. Saya senang membantu! Saya juga menikmati pemecahan masalah dan terutama membantu orang lain dengan Linux. Ada satu baris aneh di ssh-config Anda yang dapat menyebabkan masalah di mana itu berada. Apa ip 10.0.12.28?
Kyle H
@KyleH benar .. itu hampir pasti masalahnya. Saya menambahkan jawaban lain yang menunjukkan cara memperbaikinya dengan akses root. Jika Anda mengontrol homedir Anda, Anda mungkin dapat memperbaikinya sendiri, tetapi tentu saja Anda harus dapat masuk :)
Jamieson Becker
4

Untuk berjaga-jaga jika seseorang menemukan jawaban ini - tidak ada rekomendasi yang berhasil dalam skenario saya. Pada akhirnya, masalahnya adalah saya telah membuat akun tanpa kata sandi. Setelah saya mengatur kata sandi menggunakan usermod -p "my password" usernamedan kemudian secara paksa membuka kunci akun usermod -U usernamesemuanya sangat bagus.

Nathan Crause
sumber
Jawaban Anda menandai saya untuk kasus saya yang berbeda, tetapi juga terkait pengguna, ketika saya mencoba masuk ketika direktori home yang saya berikan lebih bersarang daripada yang saya masuki ... Bagus untuk diperbaiki, terima kasih!
Brett Zamir
2

Saya punya masalah yang sama , di mana koneksi ssh mencoba kunci ~/.ssh/id_rsasebelum tiba-tiba berhenti:

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

Dalam kasus saya, itu karena file kunci publik lama tergeletak di .sshdirektori:

[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

Memindahkan / menghapus id_rsa.pubdari .sshdirektori memecahkan masalah.

Dari apa yang saya mengerti: ketika ada kunci publik yang hadir di sisi klien, SSH 1 memvalidasi kunci pribadi yang menentangnya. Jika gagal, itu tidak akan mencoba menggunakan kunci pribadi untuk menghubungkan dari jarak jauh.

Saya mengirim email ke mailing list openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Elouan Keryell-Even
sumber
Yeaaahhhh. SERIUS! Saya tidak akan pernah melihatnya. openssh-8.0p1-5.fc30.x86_64btw. Saya memiliki kunci publik dari server sebelumnya dengan nama yang sama dengan yang baru tergeletak di sekitar fedora@(baloo).sshkey.pub,, yang berjalan dengan fedora@(baloo).sshkeyditeruskan pada baris perintah dengan -iopsi. Otentikasi gagal dengan kunci server baru yang ditemukan di baru fedora@(baloo).sshkey- kunci RSA.
David Tonhofer
2

Kami mengalami masalah ini. Izin dan kepemilikan pada file .ssh semuanya benar. Dalam / var / log / pesan yang kami temukan:

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, solusi untuk pengembang vm di mana kami tidak peduli dengan keamanan adalah menonaktifkan selinux. Edit / etc / sysconfig / selinux dan ubah SELINUX = nonaktif dan reboot.

gaoithe
sumber
2

Kalau-kalau ini juga menyelamatkan seseorang. Saya mencoba menyalin kunci dari Mesin Ubuntu 18.04 saya ke 2 Server CentOS 7. Saya biasa ssh-copy-idmentransfernya. Satu berhasil, satu tidak. Jadi saya pergi melalui semua izin debugging dan tidak menemukan apa pun. Jadi akhirnya saya menarik file /etc/ssh/sshd_configdi kedua server dan melangkah baris demi baris melalui mereka. Akhirnya saya menemukannya, mungkin sesuatu yang seseorang modifikasi jauh sebelum saya mulai bekerja.

Satu baca: AuthorizedKeysFile .ssh/authorized_keys

Dan baca lagi:, AuthorizedKeysFile ~/.ssh/authorized_keysyang ada di server yang tidak menerima kunci saya. Jelas melihat antara dua file dan mencatat komentar yang menyatakan pola pencarian default tidak termasuk yang ~/saya hapus dan restart sshd. Masalah terpecahkan.

Aaron Chamberlain
sumber
1

Juga menemui masalah ini. setroubleshoot sepertinya tidak berfungsi di lingkungan saya sehingga tidak ada catatan log seperti itu di / var / log / messages. Menonaktifkan SELinux bukanlah pilihan bagi saya, jadi saya lakukan

restorecon -Rv ~/.ssh

Setelah itu login dengan kunci rsa bekerja dengan baik.

lapin_
sumber
1

Alasan dalam kasus saya adalah opsi yang diatur secara khusus AuthorizedKeysFiledalam file /etc/ssh/sshd_config. Itu diatur ke dir home pengguna lain ( /home/webmaster/.ssh/authorized_keys), jadi pengguna yang saya coba masuk tidak memiliki akses ke direktori file /.

Setelah mengubahnya dan memulai kembali ssh-server ( service ssh restart) semuanya kembali normal. Saya bisa masuk dengan kunci pribadi saya sekarang.

ihoru
sumber
1

Dalam kasus kami, masalahnya terkait dengan fakta bahwa aturan firewall dan NATing kami tidak dipasang dengan benar.

port 22, sedang diarahkan ke server yang salah di mana kunci dan pengguna kami tidak dikenali.

Jika seseorang mencapai titik ini. tcpdump dan telnet bisa menjadi teman Anda

[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
^]

Anda akan melihat bahwa kedua server ini memiliki versi openssh yang berbeda. Ini membantu saya menemukan masalah dengan cukup cepat. Jika host Anda menggunakan versi ssh yang sama, Anda harus mencoba melakukan pelacakan paket di tujuan untuk melihat apakah lalu lintas benar-benar tiba di tujuan.

Ssh dapat menghasilkan banyak lalu lintas yang membuat tcpdump sulit untuk menemukan apa yang Anda cari.

Ini membantu saya

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

Coba telnet dari 3 server berbeda bukan komputer Anda saat ini @ [mylocalip]. Anda ingin melihat lalu lintas apa yang benar-benar mencapai server Anda.

nelaaro
sumber
0

Log kesalahan sisi klien berakhir seperti ini:

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:

dapat disebabkan oleh pembatasan sisi server (jarak jauh) pada login root ketika sshd file konfigurasi berisi:

PermitRootLogin: no

Saran JonCav untuk mengaktifkan logging sangat membantu dalam men-debug masalah seperti itu. Sementara memuntahkan sisi klien tidak membantu, menempatkan berikut ini di file sshd_config server sshd :

SyslogFacility AUTH
LogLevel DEBUG

akhirnya menghasilkan pesan log yang bermanfaat:

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 ...

Dalam kasus di mana hanya login root gagal, dan dengan ketentuan bahwa hanya menggunakan otentikasi berbasis kunci untuk login root diizinkan oleh kebijakan keamanan Anda, perubahan ke file sshd_config dapat membantu:

 PermitRootLogin without-password

Jarak tempuh Anda mungkin bervariasi, meskipun ini sering membantu, beberapa konfigurasi lain mungkin masih mengganggu menurut komentar yang ditemukan di beberapa file sshd_config :

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

Bahkan jika Anda tidak dapat dengan mudah mengubah konfigurasi server jarak jauh untuk melakukan debug dengan cara ini, seseorang dapat membuktikan konfigurasi sisi klien sampai batas tertentu dengan menggunakan file identitas yang sama untuk ssh ke akun non-root di server jauh yang sama.

kbulgrien
sumber
0

Saya bisa melihat mengapa keamanan dapat mengganggu orang. Saya baru saja mengalami ssh won't use my keymasalah lagi. Saya menyelesaikannya dengan masuk ke server jauh dan berjalan

/usr/sbin/sshd -sDp 23456

dan kemudian dari desktop saya, (mencoba ssh ke server)

ssh -vvvv server -p 23456

Di server saya dapatkan Authentication refused: bad ownership or modes for directory /

Beberapa sysadmin baru telah mengacaukan izin dan kepemilikan, yang saya atasi dengan:

chmod 0755 / ; chown root:root /

(Saya terbiasa membutuhkan chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubtetapi sshd memeriksa / menemukan izin root adalah yang baru bagi saya.) Sekarang saya akan memeriksa rootkit dan kemudian menghapus dan menginstal ulang pula.

Alexx Roche
sumber
0

Dalam kasus saya masalahnya adalah dengan shell eksekutif yang salah.

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

Mengubah / etc / passwd file untuk pengguna itu

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

Saya memiliki masalah ini pada CentOS 7. Saya adalah pengguna Linux berbasis Debian yang biasa jadi saya adalah ikan yang keluar dari air. Saya perhatikan bahwa di beberapa server itu bekerja dan hanya dalam satu server tidak. Audit.log mengatakan tidak ada yang berguna dan secure.log tidak memberikan apa-apa juga. Saya menemukan bahwa satu-satunya perbedaan nyata adalah beberapa perbedaan konteks keamanan pada file dan direktori antara yang bekerja dan yang tidak. Dapatkan keamanannya

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

direktori (saya mengasumsikan banyak default di sshd_config).

Anda harus melihat beberapa ssh_home_tdan user_home_tatribut. Jika tidak, gunakanchcon perintah untuk menambahkan atribut yang hilang.

Sebagai contoh

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"

Dalam kasus saya, kecurigaan saya adalah bahwa pengguna dibuat dengan cara yang tidak standar. Rumahnya adalah direktori di /var/lib.

Info lebih lanjut di: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh-authorized_keys-4175469538/

hanzo2001
sumber