Bisakah saya menggunakan otentikasi kunci SSH untuk masuk ke sistem jarak jauh dengan nama pengguna yang berbeda?

17

Misalkan saya memiliki sistem jarak jauh bernama "remotesystem", dan akun pengguna "foouser" pada sistem itu.

Saya tahu bahwa pada sistem lokal saya, saya dapat membuat pasangan kunci SSH sebagai "foouser" pengguna lokal, meletakkan kunci publik di file "/home/foouser/.ssh/authorized_keys" on "remotesystem". Ketika saya SSH sebagai "foouser" dari sistem lokal saya ke "sistem remote", SSH menggunakan pasangan kunci untuk mengotentikasi saya.

Tetapi bagaimana jika nama pengguna lokal saya tidak sama dengan nama pengguna pada sistem jarak jauh? Artinya, bagaimana jika saya ingin SSH sebagai "pengguna" pengguna lokal untuk "sistem remote"? Jelas, saya perlu membuat pasangan kunci untuk "baruser" dan menambahkan kunci publik ke "/ home / fouser / .ssh/authorized_keys". Lalu, saya harus bisa "ssh foouser @ remotesystem" saat login sebagai "baruser" secara lokal, dan SSH akan menggunakan pasangan kunci untuk mengotentikasi, kan?

Saya bertanya karena saya berusaha agar otentikasi kunci berfungsi dalam skenario ini, tanpa hasil. Saya tidak yakin apakah ini karena ketidakcocokan nama pengguna, atau masalah konfigurasi dengan server SSH pada sistem jarak jauh.

— Matt Hurne
sumber

Saya menghidupkan sisi server logging, dan terbukti menjadi masalah dengan izin pada direktori home pengguna jarak jauh. Masalah terpecahkan! Terima kasih untuk semua yang memberi jawaban.

— Matt Hurne

11

Ya, Anda bisa melakukan ini, seperti yang Anda gambarkan.

baruser @ sini ~ $ ssh-add -l
4096 10: b3: fd: 29: 08: 86: 24: a6: da: 0a: dd: c6: 1e: b0: 66: 6a id_rsa (RSA)
baruser @ sini ~ $ ssh foouser @ remotesystem
pesan motd, dll.
foouser @ remotesystem ~ $

— pengguna1686
sumber

Terima kasih atas jawabannya. Saya tahu saya tidak gila ... :-) Pasti ada yang salah dengan konfigurasi server SSH sistem jarak jauh, mencegah otentikasi kunci untuk bekerja sama sekali.

— Matt Hurne

4

Jika Anda melakukan "ssh -V foouser @ remotesystem" Anda bisa mendapatkan beberapa informasi tentang apa yang salah. Seringkali ini merupakan kesalahan izin pada ~ / .ssh.

— Paul Tomblin

4

bukan -V (menunjukkan nomor versi) tetapi -vvv (maks verbositas)

— Leven

10

Ini agak samping, tapi .....

Jika Anda selalu menggunakan nama pengguna yang sama untuk server jarak jauh, Anda mungkin juga merasa perlu menambahkan host ke konfigurasi ssh Anda:

Host remotesystem
    User baruser

Dengan begitu Anda tidak perlu mengingat untuk menentukan nama pengguna saat masuk, dan Anda mengesampingkannya saat memiliki masalah dengan kunci di masa depan.

— Menandai
sumber

5

Nama pengguna lokal Anda tidak terlalu penting (selain dari kunci pribadi harus berada di dalam direktori home pengguna lokal Anda). Cukup salin kunci ke bagian pengguna jarak jauh authorized_keysdan itu akan berfungsi.

— Sören Kuklau
sumber

3

Dengan masalah terkait ssh, hal pertama yang harus dilakukan adalah meningkatkan verbositas klien:

ssh user @ machine -vvv

Jika ini gagal memberi Anda wawasan tentang apa yang salah, Anda perlu mengubah level log di server dan me-restart daemon.

LogLevel DEBUG3

Anda harus menemukan output debug di /var/log/auth.log (atau di mana ssh dikonfigurasi untuk masuk). Setelah Anda menemukan masalah, ingatlah untuk mengembalikannya ke cara Anda menemukannya.

— David Pashley
sumber

2

Izin pada direktori .ssh pada kedua mesin jauh lebih benar. Secara umum, itu berarti 700 pada direktori .ssh dan paling banyak 755 pada direktori home. Selain 600 pada semua file di direktori .ssh.

Jika pengguna pada sistem remote adalah root, pastikan root itu ssh. (PermitRootLogin di sshd_config) dan kunci publik itu (PubkeyAuthentication) dan jika perlu RSA (RSAAuthentication) diaktifkan.

— Alexandre Carmel-Veilleux
sumber

Bukankah RSAAuthentication merupakan metode yang sepenuhnya terpisah?

— user1686

RSA adalah salah satu algoritma kunci publik yang didukung oleh SSH (bersama dengan DSA.) Itu adalah satu-satunya metode dalam SSH1.

— Alexandre Carmel-Veilleux

2

Jika Anda memiliki SE Linux diaktifkan, Anda juga perlu melakukan hal berikut.

Tambahkan label SELinux authorized_keyssehingga dapat diakses oleh sshd.

semanage fcontext -a -t sshd_key_t ~foo/.ssh/authorized_keys
restorecon -Rv ~user/.ssh

— Prof Mo
sumber

0

Kedengarannya Anda melakukan sesuatu dengan benar, tetapi pastikan izinnya benar pada otor_keys. Mereka harus diatur ke 600.

— Michael Gorsuch
sumber