Izin SSH ditolak (kunci publik), tetapi root ssh berfungsi


15

Saya mencoba untuk mengatur akses ssh untuk akun pengguna yang saya buat dengan chef di server digital laut ubuntu 12.04. Saya memiliki opsi yang diatur di lautan digital untuk secara otomatis menyalin kunci ssh mac saya ketika tetesan dibuat.

Saya dapat ssh sebagai root tanpa masalah, tetapi pengguna saya yang lain gagal mengautentikasi. ini tampaknya menjadi masalah umum, dan saya memeriksa beberapa jawaban lain, dan menemukan perintah ini untuk mendapatkan info lebih lanjut:

ssh -vvv -i id_rsa user@serverIP

Log untuk pengguna root (yang berhasil) dengan perintah itu adalah

debug

1: Offering RSA public key: /Users/evan/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug2: input_userauth_pk_ok: fp snip!
debug3: sign_and_send_pubkey: snip!
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).

pengguna yang gagal:

debug

1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/evan/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/evan/.ssh/id_dsa
debug3: no such identity: /Users/evan/.ssh/id_dsa: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.

Yang bagi saya berarti bahwa kunci publik salah. Tetapi, jika saya login sebagai pengguna root dan pergi ke home/otheraccount/.ssh/authorized_keys, saya dapat melihat bahwa kunci ssh saya ada di sana. Saya pikir mungkin ada kesalahan, jadi saya lakukan cp .ssh/authorized_keys ~/home/otheraccout/.ssh/authorized_keystetapi itu tidak membantu. Saya tidak tahu harus mencari ke mana lagi.

saya etc/ssh/sshd_conig:

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
"sshd_config" 88L, 2508C
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

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

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# GS

SAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60

AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM no
Banner /etc/ssh_banner

edit:

drwx------ 2 deploy deploy 4096 Apr 20 06:00 .ssh
-rw------- 1 deploy deploy 820 Apr 20 05:35 authorized_keys

Sunting2:

Seperti yang disarankan dalam komentar /var/log/authlog::

Apr 21 04:59:30 localhost sshd[586]: User deploy not allowed because account is locked
Apr 21 04:59:30 localhost sshd[586]: input_userauth_request: invalid user deploy [preauth]

Saya coba lakukan sudo usermod --expiredate -1 deploydan itu kembalino changes


1
Apakah izin Anda benar? ~/home/otheraccount/.sshharus memiliki 700dan ~/home/otheraccount/.ssh/authorized_keysharus memiliki 600izin dan kedua file tersebut harus dimiliki olehotheraccount
clement

Saya pikir mereka benar, deploy adalah akun lain: drwx------ 2 deploy deploy 4096 Apr 20 06:00 .ssh -rw------- 1 deploy deploy 820 Apr 20 05:35 authorized_keys
user2936314

apa baris log in serverIP( /var/log/auth.log) ketika Anda mencoba login sebagai deploypengguna?
clement

menarik, ia mengeluh bahwa pengguna terkunci, saya menambahkan log di atas.
user2936314

tidak akan membiarkan saya mengedit komentar di atas: Saya memperbaiki ini dengan passwd -u. Dapat ssh masuk seperti deploysekarang, tetapi benar-benar ingin tahu mengapa juru masak saya menciptakan pengguna yang terkunci. Harap salin / tempel komentar Anda di atas sebagai jawaban agar saya dapat memberi Anda kredit
user2936314

Jawaban:


16
  • Login SSH dapat gagal karena berbagai alasan (izin direktori / file salah, kunci salah, dll.) Dan klien yang terhubung hanya akan mendapatkan Permission deniedatau No more authentication methods to tryatau beberapa kesalahan umum.

  • Alasan pasti untuk kegagalan login akan tersedia di ssh log /var/log/auth.logatau /var/log/securetergantung pada konfigurasi syslog.


Ini adalah jawaban terbaik untuk semua pertanyaan tentang kegagalan masalah login SSH yang pernah saya lihat! Alih-alih menebak secara acak tentang izin dan nama file yang salah seperti semua jawaban lain sarankan, cukup periksa log yang disebutkan dan mereka berisi semua informasi yang Anda butuhkan!
Yaroslav Admin

Alasan tepatnya tidak ada di file log saya. Yang dikatakannya adalah bahwa sesi itu terbuka daripada tertutup.
VectorVortec

3

Masalah yang sama bagi saya menginstal CentOS7 baru.

1. periksa izin dir home dan izin ~ / .ssh dan ~ / .ssh / Authorized_key (seperti yang dikatakan @clement)

chmod o-w ~/; chmod 700 ~/.ssh; chmod 600 ~/.ssh/authorized_keys

2. centang / etc / ssh / sshd_config pengaturan && layanan sshd restart (setelah setiap pengeditan) Berguna: coba "LogLevel VERBOSE" di sshd_config.

Saya masih mendapatkan prompt kata sandi setelah memeriksa semua yang beres.

Jalankan ssh client dengan log -vvv:

debug3: send_pubkey_test 
debug2: we sent a publickey packet, wait for reply

Log server (/ var / log / secure):

Failed publickey for * from * port * ssh2: RSA *

ssh server tidak mengirim lebih banyak info kesalahan ke klien karena itu akan menjadi risiko keamanan.

Jika saya menjalankan sshd pada port yang berbeda 'sshd -p 5555 -d'. Kuncinya bekerja. Login tanpa kata sandi ok. WTF?

SAD :-( untuk mengatakan saya kemudian menonaktifkan selinux (atur SELINUX = dinonaktifkan di / etc / selinux / config) dan reboot. Login tanpa kata sandi kemudian berfungsi dengan baik.

pengaturan sshd_config saya yang aktif saat ini:

[root@hp-bl-05 ~]# grep -vE "^#|^$" /etc/ssh/sshd_config  
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
SyslogFacility AUTHPRIV
LogLevel VERBOSE
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile  .ssh/authorized_keys
HostbasedAuthentication yes
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication no
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding yes
UseDNS no
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp    /usr/libexec/openssh/sftp-server

Jadi alangkah baiknya jika kita dapat mengubah sesuatu yang kecil di selinux untuk mendapatkan login ssh tanpa kata sandi untuk bekerja. Adakah yang bisa memperbaiki jawabannya?

sama di sini: /superuser/352368/ssh-still-asks-for-password-after-setting-up-key-based-authentication/1072999#1072999

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.