SSH: Otentikasi Dua Faktor


30

Saat ini saya memiliki Ubuntu Server 12.04 yang menjalankan OpenSSH bersama dengan Samba dan beberapa layanan lainnya. Pada saat ini saya telah mengatur otentikasi kunci publik, dan saya bertanya-tanya apakah mungkin untuk mengatur otentikasi dua faktor? Saya telah mencari di Google Authenticator yang saat ini saya gunakan dengan akun Gmail saya.

Saya telah menemukan modul PAM yang sepertinya akan kompatibel tetapi tampaknya Anda dipaksa untuk menggunakan kata sandi dan kode yang dihasilkan.

Saya ingin tahu apakah ada cara untuk menggunakan Aplikasi Google Authenticator (atau yang serupa) bersama dengan kunci publik saya untuk mengautentikasi ke server SSH saya?


Sebagian besar komentar tampaknya merupakan laporan bug yang menyebutkan bahwa tidak mungkin untuk menggunakan PAM dan otentikasi kunci publik dengan OpenSSH. Saya juga menemukan bagian yang menyebutkan itu mubazir karena saya menggunakan frase sandi dengan kunci saya. Dengan semua solusi yang tampaknya hanya memungkinkan Google Authenticator dan kata sandi bukan kunci publik. Saya bisa saja melewatkannya sepenuhnya, tetapi saya tidak tahu bagaimana cara mengimplementasikan keduanya.
Keledai Beton

Tidak yakin mengapa ini memiliki -1, ini adalah pertanyaan yang sangat menarik dan saya juga ingin tahu jawabannya (bukan bahwa saya cenderung menggunakannya, tetapi meskipun demikian, bagus untuk disimpan di bank pengetahuan)
Mark Henderson

@Pierre Apakah Anda mencoba untuk meminta kedua otentikasi kunci publik, dan Google OTP?
mgorven

@ Morven Ya, saya mencoba mengatur kunci publik dan Google OTP. Saya pernah mendengar beberapa orang mengatakan itu sudah cukup sebagai memiliki frasa sandi pada jumlah kunci sebagai dua faktor, tetapi saya khawatir tentang malware mencuri kunci yang tidak dienkripsi dari memori. Saya lebih suka memiliki dua perangkat yang sepenuhnya terpisah digunakan untuk otentikasi, saya sedikit paranoid.
Keledai Beton

Ini dimaksudkan untuk diterapkan secara resmi di 6.2: bugzilla.mindrot.org/show_bug.cgi?id=983#c59
Tobias Kienzler

Jawaban:


8

Red Hat telah menambahkan tambalan ke OpenSSH di RHEL (dan karenanya CentOS) 6.3 untuk memerlukan beberapa mekanisme otentikasi, sehingga Anda dapat melakukan sesuatu seperti ini:

RequiredAuthentications2 publickey,keyboard-interactive

Lihat catatan rilis untuk tidak lebih detail.

Sayangnya fitur ini sepertinya tidak ada di OpenSSH hulu atau Ubuntu 12.04, jadi kecuali Anda ingin mencari tambalan dan mengkompilasi ulang OpenSSH saya khawatir Anda kurang beruntung.


Saya harus mengatakan saya menghargai upaya yang Anda berikan untuk menemukan jawaban bagi saya, saya tentu saja mencoba membaca beberapa halaman hasil Google tetapi semua menyiratkan apa yang Anda sebutkan bahwa saya harus menggunakan kata sandi dan hanya OTP. Saya mungkin akan membuat CentOS VM untuk bermain-main dengan fitur ini.
Keledai Beton

@Pierre Tidak itu banyak usaha, aku tahu tentang fitur ini sebelum ;-)
mgorven

Saya telah menemukan bug yang sesuai dan beberapa catatan selanjutnya . Bug termasuk tambalan sebagai lampiran.
Robie Basak

Dan inilah bug openssh upstream . Sepertinya fungsionalitas serupa akan segera dibuka di openssh.
Robie Basak

openssh 6.2 telah mendarat di rilis pengembangan Ubuntu, jadi simpan untuk bencana apa pun, dukungan ini akan ada pada rilis 13.10 yang diharapkan. Menggunakan hulu AuthenticationMethodsuntuk menentukan beberapa metode yang diperlukan, sehingga Anda dapat memerlukan kunci ssh dan PAM, dengan PAM melakukan akhir Google Authenticator.
Robie Basak

8

Anda mencari Duo Security


1
Ini. Iya nih. Saya suka benda ini!
LVLAaron

Tentunya - Duo mudah diatur untuk Unix / Linux (tautan dalam jawaban), OpenVPN ( duosecurity.com/docs/openvpn_as ), atau layanan dua faktor berbasis TOTP OATH, atau manajemen kata sandi LastPass. Layanan apa pun yang kompatibel dengan Google Authenticator (yang menggunakan TOTP) dapat digunakan dengan aplikasi seluler Duo, atau token perangkat keras yang mendukung TOTP.
RichVel

5

Anda dapat menggunakan modul PAM Google Authenticator dan kunci publik, tetapi hanya satu yang akan digunakan untuk otentikasi yang diberikan. Artinya, jika pengguna masuk dengan kunci publik yang diotorisasi, token tidak diperlukan.

Atau, untuk mengatakan sebaliknya: token hanya diperlukan untuk otentikasi kata sandi, bukan kunci SSH.

Omong-omong, pembatasan ini bukan berasal dari modul Google Authenticator, tetapi dari SSH, yang hanya mengimplementasikan dua faktor otentikasi (via ChallengeResponseAuthentication) untuk PAM, tetapi tidak memanggil PAM ketika kunci publik yang valid diberikan.


Ini benar, tetapi sekarang telah berubah. openssh 6.2 menambahkan AuthenticationMethodsparameter konfigurasi yang dapat membalik ini. Sekarang Anda dapat meminta keduanya.
Robie Basak

3

Pertanyaan ini dari 2012. Sejak, SSH telah berubah dan protokol SSH2 telah diimplementasikan.

Pada versi SSH terbaru (> = 6.2), man sshd_config menyebutkan:

AuthenticationMethods
       Specifies the authentication methods that must be successfully completed for a user to be
       granted access.  This option must be followed by one or more comma-separated lists of
       authentication method names.  Successful authentication requires completion of every method
       in at least one of these lists.

       For example, an argument of ``publickey,password publickey,keyboard-interactive'' would
       require the user to complete public key authentication, followed by either password or key-
       board interactive authentication.  Only methods that are next in one or more lists are
       offered at each stage, so for this example, it would not be possible to attempt password or
       keyboard-interactive authentication before public key.

       This option is only available for SSH protocol 2 and will yield a fatal error if enabled if
       protocol 1 is also enabled.  Note that each authentication method listed should also be
       explicitly enabled in the configuration.  The default is not to require multiple authentica-
       tion; successful completion of a single authentication method is sufficient.

Halaman ini http://lwn.net/Articles/544640/ juga menyebutkan kemungkinan menggunakan publickey dan otentikasi PAM secara bersamaan.


2

Saya tahu pertanyaan ini agak basi, tetapi demi orang-orang masa depan (termasuk saya) yang mencari solusi, ada juga pembicaraan tentang menggunakan opsi ForceCommand di file sshd_config untuk menjalankan skrip yang kemudian melakukan otentikasi. Ada contoh skrip di sini Anda dapat memodifikasi sedikit untuk kebutuhan Anda, meskipun dalam contoh itu ia memanggilnya dari file Authorized_keys alih-alih membuatnya secara sistem dengan ForceCommand milik sshd_config.


1

Dapatkan YubiKey dan ikuti panduan ini http://berrange.com/posts/2011/12/18/multi-factor-ssh-authentication-using-yubikey-and-ssh-public-keys-together/

AFAIK, ini adalah cara terbaik untuk mengimplementasikan Yubikey di server Anda untuk akses SSH. Panduan di atas memungkinkan Anda menggunakan kunci publik + yubikey sedangkan jika Anda menggunakan panduan resmi ( http://code.google.com/p/yubico-pam/wiki/YubikeyAndSSHViaPAM ), itu tidak berfungsi dengan publik- kunci.

Salam, Vip


0

Jika Anda menetapkan frasa sandi pada kunci pribadi Anda, maka Anda sudah memiliki otentikasi dua faktor. Untuk masuk, orang perlu:

  1. sesuatu yang Anda miliki - kunci pribadi Anda
  2. sesuatu yang Anda tahu - frasa sandi ke kunci pribadi Anda

3
Dua kata sandi tidak membuat otentikasi dua faktor. Kuncinya sendiri bukan "sesuatu yang Anda miliki" yang valid karena itu bukan sesuatu, hanya sepotong informasi. Masalahnya harus non-copiable, atau setidaknya non-copiable, untuk digunakan sebagai faktor otentikasi.
MadHatter mendukung Monica

2
Saya sepenuhnya tidak setuju. Jika kunci dan sertifikat bukan "sesuatu yang Anda miliki" maka apakah itu? Mereka jelas bukan "sesuatu yang Anda tahu" (apakah Anda memiliki kebiasaan mempelajari kunci SSH Anda?), Dan sama sekali bukan "sesuatu yang Anda". Hanya itu tiga pilihan, jadi dengan proses eliminasi, mereka pastinya adalah "sesuatu yang Anda miliki".
Bart B

1
Saya setuju; bagi saya, masalahnya ada di pepatah (sesuatu yang Anda tahu | ada). Gagasan otentikasi dua faktor adalah untuk meminta anggota dari dua kelas dengan sifat yang berbeda; sesuatu yang Anda tahu mudah dibawa, tetapi bisa diketahui oleh orang lain pada waktu yang sama seperti yang Anda ketahui; jadi kami menambahkan faktor kedua yang berbeda. "Sesuatu yang Anda miliki" hanya berbeda jika tidak dapat disalin (atau sulit untuk disalin). Kalau tidak, tentu saja, itu bukan sesuatu yang Anda tahu, tetapi secara kualitatif tidak berbeda dari sesuatu yang Anda tahu , karena orang lain dapat memilikinya pada saat yang sama dengan Anda.
MadHatter mendukung Monica

2
Saya setuju bahwa keypair yang dilindungi kata sandi adalah peningkatan besar dalam keamanan atas nama pengguna + kata sandi. Sayangnya, saya tidak setuju bahwa pasangan seperti itu dianggap sebagai dua faktor, dan kita mungkin harus setuju untuk tidak setuju tentang itu.
MadHatter mendukung Monica

3
Jika Anda memiliki kunci pribadi terenkripsi frasa sandi, Anda hanya membuktikan satu hal ke server: bahwa klien Anda mengetahui kunci pribadi. Itu tidak membuktikan ke server bahwa Anda tahu kata sandi Anda; server bahkan tidak tahu tentang keberadaan passphrase Anda. Oleh karena itu hanya "sesuatu yang Anda tahu" (karena klien Anda mengetahuinya) dan hanya satu faktor. Jika seorang penyerang hanya memegang satu hal (kunci pribadi Anda) maka Anda dikompromikan. Itu satu faktor. Berargumen bahwa frasa sandi dan kunci pribadi Anda dianggap sebagai dua faktor hanyalah latihan dalam kecanggihan. Yang penting adalah apa yang terjadi pada kawat.
Robie Basak
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.