ssh tidak pernah meminta kata sandi

14

Entah bagaimana SSH saya tidak pernah ingin meminta saya kata sandi.

Jadi saya mengatur VPS pada beberapa server acak di suatu tempat di dunia dan saya ingin terhubung dengannya dengan ssh.

Saya dapat mengatur kunci, tetapi ketika saya melakukan ini:

ssh -l some-user IP

Saya mendapatkan kesalahan:

Received disconnect from ##.##.##.##: 2: Too many authentication failures for some-user

Ketika saya melihat detailnya, saya dapat melihat bahwa kata sandi adalah salah satu opsi:

debug1: Offering RSA public key: some-user@computer
debug1: Authentications that can continue: publickey,password

Namun SSH tidak pernah meminta saya kata sandi. Itu mencoba 5 kali dengan apa yang saya duga adalah metode publickey dan kemudian gagal. Mengapa ssh tidak mencoba dengan kata sandi ?!

Untuk berjaga-jaga, file ssh_config saya memiliki:

PasswordAuthentication yes

Log lengkap

ssh -v -l root ##.##.##.##
OpenSSH_6.1p1 Debian-4, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/someuser/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ##.##.##.## [##.##.##.##] port 22.
debug1: Connection established.
debug1: identity file /home/someuser/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/someuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_dsa type -1
debug1: identity file /home/someuser/.ssh/id_dsa-cert type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa type -1
debug1: identity file /home/someuser/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.2p2 Ubuntu-6
debug1: match: OpenSSH_6.2p2 Ubuntu-6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1p1 Debian-4
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA XX:XX:...:XX:XX
debug1: Host '##.##.##.##' is known and matches the ECDSA host key.
debug1: Found key in /home/someuser/.ssh/known_hosts:38
debug1: ssh_ecdsa_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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/someuser/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering DSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: someuser@computer
Received disconnect from ##.##.##.##: 2: Too many authentication failures for root

ssh password

— Alexis Wilke
sumber

17

Cobalah masuk dengan Otentikasi Kunci Publik dinonaktifkan, menggunakan

ssh -o PubkeyAuthentication=no root@newserver

— Klaus-Dieter Warzecha
sumber

Baik! Itu berhasil! Saya mencoba "lawan" tanpa hasil ... (yaitu -o PasswordAuthentication=yes). Tapi ini yang saya cari.

— Alexis Wilke

3

@AlexisWilke Saya senang itu berhasil! Tapi tolong baca jawaban Olli juga. Dia benar bahwa masih ada yang salah dengan Anda .ssh/config. Ini -o PubkeyAuthentication=notidak baik sebagai solusi permanen.

— Klaus-Dieter Warzecha

Trik ini (-o PubkeyAuthentication = no) bekerja dengan baik pada mesin dengan beberapa file identitas.

— Valerio Schiavoni

17

Kemungkinan besar Anda memiliki lebih dari satu identityfilebaris di.ssh/config file .

Bahkan jika Anda memiliki identityfiledi bawah hostkonfigurasi, itu diterapkan secara global. Apa itu artinya itussh mencoba setiap file identitas (yaitu kunci publik) pada setiap host, sebelum meminta prompt kata sandi dari server.

Anda dapat memperbaikinya dengan

Menghapus semua kecuali satu identityfile baris, atau
menambahkan PubkeyAuthentication noke.ssh/config , atau
Menjalankan ssh dengan -o PubkeyAuthentication=noparameter.

Dari man 5 ssh_config:

PubkeyAuthentication
    Specifies whether to try public key authentication.  The argument to this
    keyword must be “yes” or “no”.  The default is “yes”.  This option applies 
    to protocol version 2 only.

IdentityFile
    ...
    It is possible to have multiple identity files specified in configuration
    files; all these identities will be tried in sequence.  Multiple 
    IdentityFile directives will add to the list of identities tried (this 
    behaviour differs from that of other configuration directives).

Beberapa instruksi umum dengan kunci publik:

Secara umum, Anda hanya memiliki satu kunci privat per klien (workstation), dan meletakkan kunci publik yang cocok untuk semua server yang harus diakses oleh klien. Dengan kata lain, bagikan kunci publik antar server, dan jangan pernah gunakan kunci pribadi yang sama pada banyak perangkat.
Selalu hasilkan keypair pada perangkat Anda, dan kirimkan hanya kunci publik. Dengan begitu, bahkan jika server terganggu, kunci pribadi Anda masih aman dan terlindungi. Ini bisa terjadi dengan cara yang mengejutkan - misalnya, melalui cadangan.
Jika orang lain mengelola server, Anda harus memberikan kunci publik untuk mereka; mereka seharusnya tidak menghasilkan keypair dan mengirim kunci pribadi kepada Anda. Dengan begitu, mereka tidak bisa meniru Anda dengan kunci Anda (tentu saja, biasanya mereka bisa melakukan apa pun yang mereka mau). Juga, dengan kunci publik, hanya integritas (yaitu seseorang yang tidak mengubah kunci publik) yang harus dilindungi; dengan kunci pribadi, kerahasiaan (yaitu tidak ada orang lain yang mendapatkan kunci) harus dilestarikan, dan tidak mungkin untuk benar-benar yakin itu tidak dikompromikan.
Mengompromikan server tidak membahayakan server lain, bahkan jika Anda menggunakan kunci pribadi yang sama untuk menghubungkan ke beberapa server (kecuali jika Anda mengirim kunci pribadi itu ke server. Jangan pernah melakukannya.)
Mengompromikan workstation Anda akan mengekspos kunci pribadi Anda. Memiliki beberapa kunci pribadi tidak membantu dengan ini (kecuali jika Anda memiliki frasa sandi yang kuat dan berbeda, dan tidak semua tersedia untuk penyerang).

Ada beberapa pengecualian untuk ini, tetapi tidak terlalu banyak.

— Olli
sumber

2

Aaah! Saya memiliki "terlalu banyak" mengidentifikasi file dan memeriksa dengan 5 dari mereka dan berhenti. Mengerti! Itu menjelaskan semuanya. Saya kira saya harus memindahkan semua itu dalam sub-folder sehingga dengan demikian mereka tidak akan ditemukan secara otomatis dan fitur kata sandi akan bekerja secara otomatis lagi ...

— Alexis Wilke

3

Jika memungkinkan, Anda harus / hanya dapat menggunakan kunci publik tunggal untuk setiap layanan yang Anda butuhkan. Sangat jarang ada alasan untuk melakukannya dengan cara lain. Jika seseorang mencuri kunci publik Anda (konten authorized_keys), mereka tidak dapat melakukan apa-apa dengan itu. Dan jika semua kunci pribadi Anda ( id_rsa/ id_dsa) berada di komputer yang sama, menggunakan lebih dari satu tidak masalah.

— Olli

4

Ssh lokal Anda seharusnya tidak meminta kata sandi, server ssh di ujung yang lain harus. Kemungkinan server diatur untuk tidak menerima otentikasi kata sandi. Milik saya tidak akan meminta Anda kata sandi juga.

— Marc
sumber

1

Server lain adalah server baru dan mereka meminta Anda untuk melakukan hal itu. Tidak hanya itu, pasangan saya bisa masuk tanpa masalah! Ada sesuatu yang mencurigakan di komputer saya yang mencegahnya menguji kata sandi ... Sebenarnya, jika Anda melihat log, autentikasi resmi TIDAK termasuk "kata sandi". Oleh karena itu, klien ssh lokal saya HARUS meminta kata sandi, tetapi memutuskan untuk melewatinya.

— Alexis Wilke

Lebih mudah untuk melihat mengapa server tidak akan meminta Anda untuk kata sandi daripada melihat mengapa klien Anda tidak akan memberi Anda opsi itu jika server menawarkannya. Ada banyak opsi konfigurasi di ujungnya, dan sedikit yang terkutuk di tangan Anda. Ada kemungkinan bahwa seseorang dengan alamat IP Anda telah mencoba masuk berkali-kali tanpa kata sandi yang benar, dan upaya selanjutnya dari IP Anda telah dinonaktifkan. Tembak, saya baru saja membaca jawaban Olli. Itu dia.

— Marc