Menambahkan kunci publik ke ~ / .ssh /otorized_keys tidak masuk secara otomatis

Saya menambahkan kunci SSH publik ke file otor_keys . ssh localhostharus login saya tanpa meminta kata sandi.

Saya melakukan itu dan mencoba mengetik ssh localhost, tetapi masih meminta saya untuk mengetikkan kata sandi. Apakah ada pengaturan lain yang harus saya lalui untuk membuatnya bekerja?

Saya telah mengikuti instruksi untuk mengubah izin:

Di bawah ini adalah hasilnya jika saya melakukannya ssh -v localhost.

debug1: Reading configuration data /home/john/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to localhost [127.0.0.1] port 22.
debug1: Connection established.
debug1: identity file /home/john/.ssh/identity type 1
debug1: identity file /home/john/.ssh/id_rsa type -1
debug1: identity file /home/john/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7p1 Debian-8ubuntu3
debug1: match: OpenSSH_4.7p1 Debian-8ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu3
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc 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: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /home/john/.ssh/known_hosts:12
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/john/.ssh/identity
debug1: Server accepts key: pkalg ssh-rsa blen 149
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>

Kemudian ia meminta kata sandi setelah log di atas. Mengapa saya tidak masuk tanpa kata sandi?

Anda perlu memverifikasi izin authorized_keysfile dan folder / folder induk di mana ia berada.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Untuk informasi lebih lanjut lihat halaman ini .

Anda juga mungkin perlu mengubah / memverifikasi izin direktori home Anda untuk menghapus akses tulis untuk grup dan lainnya.

chmod go-w ~

SELinux juga dapat menyebabkan berwenang_kunci tidak berfungsi. Khusus untuk root di CentOS 6 dan 7. Tidak perlu menonaktifkannya. Setelah Anda memverifikasi izin Anda sudah benar, Anda dapat memperbaikinya seperti ini:

chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
restorecon -R -v /root/.ssh

pengaturan ssh official_keys tampaknya sederhana tetapi menyembunyikan beberapa jebakan yang saya coba bayangkan

- SERVER -

di / etc / ssh / sshd_config diatur passwordAuthentication yesuntuk membiarkan server menerima otentikasi kata sandi sementara

-- KLIEN --

pertimbangkan cygwin sebagai emulasi linux dan instal & jalankan openssh

1. menghasilkan kunci pribadi dan publik (sisi klien) # ssh-keygen

di sini dengan menekan ENTER Anda mendapatkan file DEFAULT 2 " id_rsa " dan " id_rsa.pub " di ~ / .ssh / tetapi jika Anda memberi nama_for_the_key file yang dihasilkan disimpan di pwd Anda

2. tempatkan your_key.pub ke mesin targetssh-copy-id user_name@host_name

jika Anda tidak membuat kunci default, ini adalah langkah pertama yang salah ... Anda harus menggunakan

ssh-copy-id -i path/to/key_name.pub user_name@host_name

3. logging ssh user_name@host_namehanya akan berfungsi untuk id_rsa default jadi di sini adalah jebakan ke-2 yang perlu Anda lakukanssh -i path/to/key_name user@host

(gunakan ssh -v ... opsi untuk melihat apa yang terjadi)

Jika server masih meminta kata sandi maka Anda memberikan sesuatu untuk memasukkan frasa sandi: memasukkan ketika Anda telah membuat kunci (jadi itu normal)

jika ssh tidak mendengarkan port default 22 harus digunakan ssh -p port_nr

- SERVER -----

4. ubah / etc / ssh / sshd_config untuk dimiliki

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  %h/.ssh/authorized_keys

(uncoment if case)

Ini memberi tahu ssh untuk menerima kuasa_kunci dan mencari di direktori home pengguna untuk sengatan key_name yang ditulis dalam file .ssh / Authorized_key

5 set izin di mesin target

chmod 755 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Juga matikan pass auth

passwordAuthentication no

untuk menutup gerbang ke semua upaya ssh root / admin /....@ your_domain

6 memastikan kepemilikan dan kepemilikan grup dari semua direktori home non-root sesuai.

chown -R ~ usernamehere
chgrp -R ~/.ssh/ user 

===============================================

7. pertimbangkan http://www.fail2ban.org yang sangat baik

8. TUNNEL ssh tambahan untuk mengakses server MySQL (bind = 127.0.0.1)

Juga pastikan direktori home Anda tidak dapat ditulisi oleh orang lain

chmod g-w,o-w /home/USERNAME

Jawabannya dicuri dari sini

yang putus asa juga dapat memastikan mereka tidak memiliki baris baru tambahan dalam file Authorized_key karena menyalin teks id_rsa.pub dari terminal yang bingung.

pengguna adalah nama pengguna Anda

mkdir -p /home/user/.ssh
ssh-keygen -t rsa
touch /home/user/.ssh/authorized_keys
touch /home/user/.ssh/known_hosts
chown -R user:user /home/user/.ssh
chmod 700 /home/user/.ssh
chmod 600 /home/user/.ssh/id*
chmod 644 /home/user/.ssh/id*.pub
chmod 644 /home/user/.ssh/authorized_keys
chmod 644 /home/user/.ssh/known_hosts

Hati-hati bahwa SELinux juga dapat memicu kesalahan ini, meskipun semua izin tampaknya baik-baik saja. Menonaktifkan itu merupakan trik untuk saya (masukkan penafian biasa tentang menonaktifkannya).

Daftar kunci publik di .ssh / authorized_key diperlukan, tetapi tidak cukup untuk sshd (server) untuk menerimanya. Jika kunci pribadi Anda dilindungi frasa sandi, Anda harus memberikan ssh (klien) frasa sandi setiap kali. Atau Anda dapat menggunakan ssh-agent , atau yang setara dengan GNOME.

Jejak Anda yang diperbarui konsisten dengan kunci pribadi yang dilindungi frasa sandi. Lihat ssh-agent, atau gunakan ssh-keygen -p.

Tulis perintah:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Setelah Anda melakukan ini, pastikan dir Anda seperti itu:

drwx------ 2 lab lab 4.0K Mar 13 08:33 .
drwx------ 8 lab lab 4.0K Mar 13 08:07 ..
-rw------- 1 lab lab  436 Mar 13 08:33 authorized_keys
-rw------- 1 lab lab 1.7K Mar 13 07:35 id_rsa
-rw-r--r-- 1 lab lab  413 Mar 13 07:35 id_rsa.pub

Hal yang akhirnya berhasil bagi saya adalah memastikan bahwa pemilik / grup bukan root tetapi pengguna:

chown -R ~/.ssh/ user
chgrp -R ~/.ssh/ user 

Coba "ssh-add" yang berfungsi untuk saya.

Tip lain yang perlu diingat. Sejak v7.0 OpenSSH menonaktifkan kunci DSS / DSA ssh secara default karena kelemahan bawaannya. Jadi, jika Anda memiliki OpenSSH v7.0 +, pastikan kunci Anda tidak ssh-dss.

Jika Anda terjebak dengan kunci DSA, Anda dapat mengaktifkan kembali dukungan lokal dengan memperbarui Anda sshd_configdan ~/.ssh/configfile dengan garis-garis seperti:PubkeyAcceptedKeyTypes=+ssh-dss

Dalam kasus saya, saya perlu memasukkan authorized_keysfile saya .openssh.

Lokasi ini ditentukan di /etc/ssh/sshd_configbawah opsi AuthorizedKeysFile %h/.ssh/authorized_keys.

Pastikan bahwa pengguna target memiliki kumpulan kata sandi. Jalankan passwd usernameuntuk mengatur satu. Ini diperlukan untuk saya bahkan jika kata sandi SSH login dinonaktifkan.

ini menyelesaikan masalah saya

pesta ssh-agent

ssh-add

Masalah lain Anda harus berhati-hati. Jika file yang Anda buat tidak default id_rsa dan id_rsa.pub

Anda harus membuat file .ssh / config dan menentukan secara manual file id mana yang akan Anda gunakan dengan koneksi.

Contohnya ada di sini:

host remote_host_name
hostname 172.xx.xx.xx
user my_user
IdentityFile /home/my_user/.ssh/my_user_custom.pub

Saya mengeluarkan sudo chmod 700 ~/.sshdan chmod 600 ~/.ssh/authorized_keysdan chmod go-w $HOME $HOME/.sshdari atas dan itu memperbaiki masalah saya pada kotak CentOS7 yang saya telah mengacaukan izin ketika mencoba untuk membuat saham samba bekerja. Terima kasih

Sepertinya masalah izin. Biasanya itu terjadi jika izin beberapa file / direktori tidak diatur dengan benar. Dalam kebanyakan kasus mereka ~/.sshdan ~/.ssh/*. Dalam kasus saya mereka /home/xxx.

Anda dapat mengubah level log sshd dengan memodifikasi /etc/ssh/sshd_config(mencari LogLevel, mengaturnya menjadiDEBUG ), kemudian memeriksa output /var/log/auth.loguntuk melihat apa yang terjadi secara tepat.

Masalah saya adalah AuthorizedKeysFile yang dimodifikasi, ketika otomasi untuk mengisi / etc / ssh / official_keys belum dijalankan.

$sudo grep AuthorizedKeysFile /etc/ssh/sshd_config
#AuthorizedKeysFile .ssh/authorized_keys
AuthorizedKeysFile  /etc/ssh/authorized_keys/%u

Lihat saja /var/log/auth.log di server . Menyetel verbositas tambahan dengan -vv di sisi klien tidak akan membantu, karena server tidak mungkin menawarkan terlalu banyak informasi kepada penyerang yang mungkin.

Pastikan Anda telah menyalin seluruh kunci publik ke authorized_keys; yang ssh rsaawalan diperlukan untuk kunci untuk bekerja.

Anda perlu memverifikasi properti file. untuk menetapkan penggunaan properti yang diperlukan:

$ chmod 600 ~/.ssh/sshKey
$ chmod 644 ~/.ssh/sshKey.pub

Lihat di /var/log/auth.logserver untuk sshdkesalahan auth.

Jika semuanya gagal, maka jalankan sshdserver dalam mode debug:

sudo /usr/sbin/sshd -ddd -p 2200

Kemudian hubungkan dari klien:

ssh user@host -p 2200

Dalam kasus saya, saya menemukan bagian kesalahan di akhir:

    debug1: userauth_pubkey: test whether pkalg/pkblob are acceptable for RSA SHA256:6bL+waAtghY5BOaY9i+pIX9wHJHvY4r/mOh2YaL9RvQ [preauth]
==> debug2: userauth_pubkey: disabled because of invalid user [preauth]
    debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa [preauth]
    debug3: userauth_finish: failure partial=0 next methods="publickey,password" [preauth]
    debug3: send packet: type 51 [preauth]
    debug3: receive packet: type 50 [preauth]

Dengan info ini saya menyadari bahwa saya sshd_configmembatasi login ke anggota sshgrup. Perintah berikut memperbaiki kesalahan izin ini:

sudo usermod -a -G ssh NEW_USER

pada catatan itu, pastikan Anda sshd config telah -;

PermitRootLogin without-password

atur seperti di atas, kemudian restart sshd (/etc/init.d/sshd restart)

log-out dan coba masuk lagi!

default saya percaya adalah -;

PermitRootLogin no

Dalam kasus saya itu karena grup pengguna tidak disetel di AllowGroups dari file config / etc / ssh / sshd_config. Setelah menambahkan semuanya bekerja dengan baik.

Saya memiliki direktori home di lokasi non-standar dan dalam sshdlog saya memiliki baris ini:

Could not open authorized keys '/data/home/user1/.ssh/authorized_keys': Permission denied

bahkan jika semua izin baik-baik saja (lihat jawaban lain).

Saya telah menemukan solusi di sini: http://arstechnica.com/civis/viewtopic.php?p=25813191&sid=0876f069ec2aa5fdcd691a2e2e7242c2#p25813191

Dalam kasus khusus saya:

• menambahkan baris baru di /etc/selinux/targeted/contexts/files/file_contexts.homedirs:

  • ini adalah baris asli untuk direktori home biasa:

    /home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

  • ini adalah baris baru saya:

    /data/home/[^/]*/\.ssh(/.*)? unconfined_u:object_r:ssh_home_t:s0

• diikuti oleh restorecon -r /data/dan sshdrestart

Aku punya masalah ini dan tidak ada jawaban yang lain dipecahkan itu, walaupun tentu saja jawaban yang lain adalah benar.

Dalam kasus saya, ternyata /rootdirektori itu sendiri (bukan eg /root/.ssh) memiliki izin yang salah. Saya memerlukannya:

chown root.root /root
chmod 700 /root

Tentu saja, izin itu harus seperti itu (mungkin chmod 770) terlepas. Namun, itu secara khusus mencegah sshdbekerja, meskipun /root/.sshdan /root/.ssh/authorized_keyskeduanya memiliki izin dan pemilik yang benar.

Saya mengalami masalah ini ketika saya menambahkan grup pengguna login ke pengguna lain. Katakanlah ada pengguna ssh-login yang disebut userA dan pengguna non-ssh-login B. userA memiliki grup userA juga. Saya memodifikasi userB untuk memiliki grup userA juga. Arahan ke perilaku yang dijelaskan, sehingga userA tidak dapat masuk tanpa prompt. Setelah saya menghapus userA grup dari userB, login tanpa prompt berhasil lagi.