Bagaimana cara mengkonfigurasi SSH sehingga ia tidak mencoba semua file identitas secara otomatis?

90

Saya telah meletakkan file identitas ssh saya di dalam folder ~ / .ssh / saya. Saya mungkin memiliki sekitar 30 file di sana.

Ketika saya terhubung ke server, saya akan menentukan file identitas yang akan digunakan, dengan sesuatu seperti 

ssh -i ~/.ssh/client1-identity client1@10.1.1.10

Namun, jika saya tidak menentukan file identitas, dan hanya menggunakan sesuatu seperti ini: 

ssh user123@example.com

Saya mendapatkan kesalahan 

Too many authentication failures for user123

Saya mengerti itu karena jika tidak ada file identitas yang ditentukan, dan ssh dapat menemukan file identitas, maka akan mencoba semuanya.

Saya juga mengerti bahwa saya dapat mengedit ~/.ssh/config file dan tentukan sesuatu seperti: 

Host example.com
PreferredAuthentications keyboard-interactive,password

untuk mencegah koneksi dari mencoba file identitas yang diketahui.

Jadi, saya kira saya bisa memindahkan file identitas saya di luar ~/.ssh/ direktori, atau saya bisa menentukan setiap host yang saya ingin menonaktifkan otentikasi file identitas dalam file konfigurasi, tetapi apakah ada cara untuk memberitahu SSH untuk membeli default bukan mencari file identitas? Atau untuk menentukan yang akan dicari?

linux  unix  authentication  ssh 
— cwd
sumber
3
Re "Saya mengerti itu karena ..." - gunakan ssh -v untuk mencari tahu pasti.
— grawity

Jawaban:

84

Anda dapat menggunakan IdentitiesOnly=yes opsi bersama IdentityFile (Lihat halaman manual ssh_config ). Dengan begitu, Anda dapat menentukan file mana yang harus dicari.

Dalam contoh ini, ssh akan hanya lihat identitas yang diberikan dalam file ssh_config + 4 yang terdaftar di baris perintah (identitas yang diberikan oleh agen akan diabaikan): 

ssh -o IdentitiesOnly=yes \
    -o IdentityFile=id1.key \
    -o IdentityFile=id2.key \
    -i id3.key \
    -i id4.key \
    user123@example.com

Bentuk -i dan -o IdentityFile= dipertukarkan.

— init_js
sumber
7
Sebuah contoh akan menyenangkan
— rubo77
Bukan itu: IdentitiesOnly yes (tanpa "=")?
— Dimitrios Mistriotis
2
@DimitriosMistriotis Menurut halaman manual ssh_config, keduanya dapat diterima: Configuration options may be separated by whitespace or optional whitespace and exactly one '='; the latter format is useful to avoid the need to quote whitespace when specifying configuration options using the ssh, scp, and sftp -o option.
— Nick Anderegg
76

Jawaban singkat user76528 benar, tetapi saya baru saja mengalami masalah ini dan berpikir beberapa elaborasi akan berguna. Anda mungkin juga peduli dengan solusi ini jika Anda bertanya-tanya "Mengapa ssh mengabaikan opsi konfigurasi identityfile saya"?

Pertama, tidak seperti setiap opsi lain di ssh_config, ssh tidak menggunakan yang pertama IdentityFile yang ditemukannya. Sebaliknya IdentityFile opsi menambahkan file itu ke daftar identitas yang digunakan. Anda dapat menumpuk banyak IdentityFile opsi, dan klien ssh akan mencoba semuanya sampai server menerima satu atau menolak koneksi.

Kedua, jika Anda menggunakan ssh-agent, ssh akan secara otomatis mencoba menggunakan kunci di agen, bahkan jika Anda belum menentukannya dengan opsi IdentityFile (atau -i) ssh_config. Ini adalah alasan umum Anda mungkin mendapatkan Too many authentication failures for user kesalahan. Menggunakan IdentitiesOnly yes Opsi akan menonaktifkan perilaku ini.

Jika Anda ssh sebagai banyak pengguna ke banyak sistem, saya sarankan menempatkan IdentitiesOnly yes di bagian global Anda dari ssh_config, dan menempatkan masing-masing IdentityFile dalam subbagian Host yang sesuai.

— chrishiestand
sumber
4
menjelaskan dengan baik, terima kasih. Tidak jelas bahwa parameter 'IdentitiesOnly' artinya TakeOnlyWhatIExplicitlySpecifyThenFailoverToPassword . Dan ternyata, kunci ./ssh/id_rsa masih terdaftar.
— lImbus
Puting IdentitiesOnly yes di bagian global dari ssh_config adalah apa yang dilakukan untuk saya. Terima kasih!
— jamix
Terima kasih atas komentar terinci. Saya biasa menggunakan ('\' untuk baris baru) Host * \ IdentityFile ~/.ssh/mykey sebagai opsi konfigurasi, dan pada awalnya tampak aneh bahwa memiliki entri berbeda untuk situs tertentu, mis. Host special \ IdentityFile ~/.ssh/specialkey \ IdentitiesOnly yes terus memasok mykey dari pada specialkey. Jelas tidak jelas, sampai saya menyadari (dari jawaban Anda) bahwa entri IdentityFile ditumpuk dalam urutan evaluasi dan yang terakhir akan digunakan. Menghapus IdentityFile ~/.ssh/mykey memecahkan masalah, dan kunci tunggal yang benar digunakan.
— Ryder
Sebelum saya mencoba ini, saya perhatikan git pull/push perintah mencoba setiap identitas yang dimuat di agen saya. Itu tidak masalah sampai pada satu titik saya punya terlalu banyak kunci.
— sdkks
17

Saya biasanya melakukannya seperti ini: 

$ ssh -o IdentitiesOnly=yes -F /dev/null -i ~/path/to/some_id_rsa root@server.mydom.com

Opsinya adalah sebagai berikut:

  • -o IdentitiesOnly=yes - Memberitahu SSH untuk hanya menggunakan kunci yang disediakan melalui CLI dan tidak ada dari $HOME/.ssh atau melalui ssh-agent
  • -F /dev/null - Menonaktifkan penggunaan $HOME/.ssh/config
  • -i ~/path/to/some_id_rsa - kunci yang ingin Anda gunakan secara eksplisit untuk koneksi

Contoh 

$ ssh -v -o IdentitiesOnly=yes -F /dev/null -i ~/my_id_rsa root@someserver.mydom.com
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /dev/null
debug1: Connecting to someserver.mydom.com [10.128.12.124] port 22.
debug1: Connection established.
debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3
debug1: match: OpenSSH_5.3 pat OpenSSH_5*
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr 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: Server host key: RSA f5:60:30:71:8c:a3:da:a3:fe:b1:6d:0b:20:87:23:e1
debug1: Host 'someserver' is known and matches the RSA host key.
debug1: Found key in /Users/sammingolelli/.ssh/known_hosts:103
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to someserver.mydom.com ([10.128.12.124]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
Last login: Tue Dec  8 19:03:24 2015 from 153.65.219.15
someserver$

Perhatikan pada output di atas itu ssh hanya mengidentifikasi my_id_rsa kunci pribadi melalui CLI dan itu menggunakannya untuk terhubung ke someserver.

Khususnya bagian ini: 

debug1: identity file /Users/sammingolelli/my_id_rsa type 1
debug1: identity file /Users/sammingolelli/my_id_rsa-cert type -1

dan: 

debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/sammingolelli/my_id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 535
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
— slm
sumber
1
Terima kasih, ini adalah satu-satunya solusi lengkap. Tampaknya, -F /dev/null adalah bagian yang hilang dalam jawaban lainnya.
— leden
9

Dalam skenario di mana Anda memiliki banyak kunci, Anda akan selalu mengalami kesalahan "Terlalu Banyak Kegagalan Otentikasi". Jika Anda memiliki kata sandi, dan hanya ingin menggunakan kata sandi untuk masuk, berikut adalah cara melakukannya.

Untuk menggunakan HANYA otentikasi kata sandi dan BUKAN menggunakan kunci Publik, dan BUKAN menggunakan "keyboard-interactive" yang agak menyesatkan (yang merupakan superset termasuk kata sandi), Anda dapat melakukan ini dari baris perintah: 

ssh -o PreferredAuthentications=password user@example.com
— Greg Rundlett
sumber
6

Gunakan IdentityFile tetapi Tetap Menggunakan ssh-agent untuk Menghindari Passphrase Reprompts

Solusi penggunaan yang diterima IdentitiesOnly yes berarti Anda tidak akan pernah dapat mengambil keuntungan dari ssh-agent, menghasilkan permintaan berulang untuk frasa sandi Anda saat memuat kunci Anda.

Untuk terus menggunakan ssh-agent dan menghindari kesalahan 'Terlalu banyak kegagalan otentikasi', coba ini:

  1. Hapus semua skrip startup konsol interaktif yang secara otomatis memuat kunci ssh-agent.

  2. menambahkan AddKeysToAgent yes ke konfigurasi ssh klien Anda. Ini akan meminta Anda untuk frasa sandi pada koneksi pertama, tetapi kemudian menambahkan kunci ke agen Anda.

  3. menggunakan ssh-add -D ketika Anda mendapatkan kesalahan 'terlalu banyak otentikasi'. Ini hanya 'me-reset' (menghapus) cache ssh-agent Anda. Kemudian coba koneksi lagi dalam sesi yang sama. Anda akan dimintai kata sandi, dan setelah diterima, kata itu akan ditambahkan ke agen Anda. Karena Anda hanya memiliki satu kunci di agen Anda, Anda akan diizinkan untuk terhubung. ssh-agent kemudian masih ada untuk koneksi di masa depan selama sesi yang sama untuk menghindari reprompts. 

    Host ex example.com
   User joe
   HostName example.com
   PreferredAuthentications publickey,password
   IdentityFile /path/to/id_rsa
   AddKeysToAgent yes
— AndrewD
sumber
Apakah pada saat menerima kunci ditambahkan ke gantungan kunci?
— vfclists
1

Klien ssh dan ssh-agent berkomunikasi melalui soket domain Unix yang namanya ditentukan untuk klien oleh variabel lingkungan SSH_AUTH_SOCK (ditetapkan oleh agen saat startup-nya).

Dengan demikian, untuk mencegah satu permintaan klien dari permintaan agen, variabel ini dapat diatur secara eksplisit untuk sesuatu yang tidak valid, seperti string kosong; 

$ SSH_AUTH_SOCK= ssh user@server

Doa klien seperti ini akan gagal berkomunikasi dengan agen dan hanya dapat menawarkan identitas yang tersedia sebagai file di ~ / .ssh /, atau apa pun yang ditentukan pada baris perintah menggunakan -i, ke server. 

debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused
— mikini
sumber
0

Anda punya jawaban selama ini (hampir): 

Host *
PreferredAuthentications keyboard-interactive,password

Bekerja untukku.

— Henry Grebler
sumber
8
Pertanyaan yang diajukan tentang bagaimana membatasi kunci publik mana yang digunakan. Jawaban ini sepenuhnya menonaktifkan otentikasi kunci publik.
— chrishiestand
1
Saya memberi +1 karena itu adalah jawaban yang saya cari di Google, terima kasih @ Henry Grebler
— matiu
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.