Tại sao tôi vẫn nhận được lời nhắc mật khẩu với ssh với xác thực khóa chung?

Tôi đang làm việc từ URL tôi tìm thấy ở đây:

http://web.archive.org/web/20160404025901/http://jaybyjayfresh.com/2009/02/04/logging-in-without-a-password-certert-ssh/

Máy khách ssh của tôi là máy tính để bàn Ubuntu 64 bit 11.10 và máy chủ của tôi là Centos 6.2 64 bit. Tôi đã làm theo hướng dẫn. Tôi vẫn nhận được một dấu nhắc mật khẩu trên ssh.

Tôi không biết phải làm gì tiếp theo.

Hãy chắc chắn rằng các quyền trên ~/.sshthư mục và nội dung của nó là đúng. Khi tôi lần đầu tiên thiết lập khóa ssh auth, tôi đã không ~/.sshcài đặt đúng thư mục và nó đã mắng tôi.

• Thư mục nhà của bạn ~, thư mục của bạn ~/.sshvà ~/.ssh/authorized_keystệp trên máy từ xa chỉ có thể ghi được bởi bạn: rwx------và rwxr-xr-xvẫn ổn, nhưng rwxrwx---không tốt, ngay cả khi bạn là người dùng duy nhất trong nhóm của bạn (nếu bạn thích chế độ số: 700hoặc 755, không 775) .
  Nếu ~/.sshhoặc authorized_keyslà một liên kết tượng trưng, đường dẫn chính tắc (với các liên kết tượng trưng được mở rộng) được chọn .
• Tệp của bạn ~/.ssh/authorized_keys(trên máy từ xa) phải có thể đọc được (ít nhất 400), nhưng bạn sẽ cần nó cũng có thể ghi được (600) nếu bạn sẽ thêm bất kỳ phím nào vào đó.
• Tệp khóa riêng của bạn (trên máy cục bộ) chỉ có thể đọc và ghi được bởi bạn : rw-------, tức là 600.
• Ngoài ra, nếu SELinux được thiết lập để thực thi, bạn có thể cần phải chạy restorecon -R -v ~/.ssh(xem ví dụ về lỗi Ubuntu 965663 và báo cáo lỗi Debian # 658675 ; điều này được vá trong CentOS 6 ).

¹ _{ngoại trừ trên một số phân phối (Debian và các dẫn xuất) đã vá mã để cho phép nhóm writability nếu bạn là người dùng duy nhất trong nhóm của bạn.}

Nếu bạn có quyền truy cập root vào máy chủ, cách dễ dàng để giải quyết các vấn đề đó là chạy sshd trong chế độ gỡ lỗi, bằng cách phát hành một cái gì đó như /usr/sbin/sshd -d -p 2222trên máy chủ (yêu cầu đầy đủ đường dẫn đến sshd thực thi, which sshdcó thể trợ giúp) và sau đó kết nối từ máy khách ssh -p 2222 user@host. Điều này sẽ buộc daemon SSH ở lại nền trước và hiển thị thông tin gỡ lỗi về mọi kết nối. Tìm kiếm một cái gì đó như

debug1: trying public key file /path/to/home/.ssh/authorized_keys
...
Authentication refused: bad ownership or modes for directory /path/to/home/

Nếu không thể sử dụng một cổng thay thế, bạn có thể tạm thời dừng trình nền SSH và thay thế nó bằng một cổng trong chế độ gỡ lỗi. Dừng trình nền SSH không giết được các kết nối hiện có để có thể thực hiện việc này thông qua một thiết bị đầu cuối từ xa, nhưng hơi nguy hiểm - nếu kết nối bị hỏng bằng cách nào đó tại thời điểm khi thay thế gỡ lỗi không chạy, bạn sẽ bị khóa khỏi máy cho đến khi bạn có thể khởi động lại nó Các lệnh cần thiết:

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

(Tùy thuộc vào bản phân phối Linux của bạn, dòng đầu tiên / cuối cùng có thể là systemctl stop sshd.service/ systemctl start sshd.servicethay vào đó.)

Là dir nhà của bạn được mã hóa? Nếu vậy, đối với phiên ssh đầu tiên của bạn, bạn sẽ phải cung cấp mật khẩu. Phiên ssh thứ hai cho cùng một máy chủ đang hoạt động với khóa auth. Nếu đây là trường hợp, bạn có thể di chuyển authorized_keysđến một thư mục không được mã hóa và thay đổi đường dẫn trong ~/.ssh/config.

Điều cuối cùng tôi làm là tạo một /etc/ssh/usernamethư mục, được sở hữu bởi tên người dùng, với các quyền chính xác và đặt authorized_keystệp vào đó. Sau đó thay đổi chỉ thị AuthorizedKeysFile /etc/ssh/configthành:

AuthorizedKeysFile    /etc/ssh/%u/authorized_keys

Điều này cho phép nhiều người dùng có quyền truy cập ssh này mà không ảnh hưởng đến quyền.

Sau khi sao chép các phím vào máy từ xa và đặt chúng vào trong, authorized_keysbạn phải làm một cái gì đó như thế này:

ssh-agent bash
ssh-add ~/.ssh/id_dsa or id_rsa

Chỉ cần thử các lệnh sau

1. ssh-keygen

   Nhấn phím Enter cho đến khi bạn nhận được lời nhắc

2. ssh-copy-id -i root@ip_address

   (Nó sẽ yêu cầu mật khẩu của hệ thống máy chủ một lần)

3. ssh root@ip_address

   Bây giờ bạn có thể đăng nhập mà không cần bất kỳ mật khẩu

Tôi đã đối mặt với những thách thức khi thư mục nhà trên điều khiển từ xa không có đặc quyền chính xác. Trong trường hợp của tôi, người dùng đã thay đổi thư mục nhà thành 777 cho một số quyền truy cập cục bộ trong nhóm. Máy không thể kết nối với các phím ssh nữa. Tôi đã thay đổi quyền thành 744 và nó bắt đầu hoạt động trở lại.

SELinux trên RedHat / CentOS 6 có vấn đề với xác thực pubkey , có thể khi một số tệp được tạo, selinux không đặt ACL chính xác.

Để sửa lỗi thủ công ACL SElinux cho người dùng root:

restorecon -R -v /root/.ssh

Chúng tôi gặp vấn đề tương tự và chúng tôi đã làm theo các bước trong câu trả lời. Nhưng nó vẫn không làm việc cho chúng tôi. Vấn đề của chúng tôi là đăng nhập làm việc từ một khách hàng nhưng không phải từ một khách hàng khác (thư mục .ssh được gắn NFS và cả hai khách hàng đang sử dụng cùng một khóa).

Vì vậy, chúng tôi đã phải đi một bước xa hơn. Bằng cách chạy lệnh ssh trong chế độ dài, bạn sẽ có được nhiều thông tin.

ssh -vv user@host

Những gì chúng tôi phát hiện ra là khóa mặc định (id_rsa) không được chấp nhận và thay vào đó, máy khách ssh cung cấp một khóa khớp với tên máy chủ của máy khách:

debug1: Offering public key: /home/user/.ssh/id_rsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: /home/user/.ssh/id_dsa                                    
debug2: we sent a publickey packet, wait for reply                                        
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: user@myclient                                          
debug2: we sent a publickey packet, wait for reply                                        
debug1: Server accepts key: pkalg ssh-rsa blen 277                  

Rõ ràng điều này sẽ không hoạt động từ bất kỳ khách hàng khác.

Vì vậy, giải pháp trong trường hợp của chúng tôi là chuyển khóa rsa mặc định sang khóa có chứa user @ myclient. Khi một khóa được mặc định, không có kiểm tra tên khách hàng.

Sau đó, chúng tôi gặp vấn đề khác, sau khi chuyển đổi. Rõ ràng các khóa được lưu trong bộ đệm ssh cục bộ và chúng tôi đã gặp lỗi sau trong nhật ký gỡ lỗi:

'Agent admitted failure to sign using the key'

Điều này đã được giải quyết bằng cách tải lại các khóa cho tác nhân ssh:

ssh-add

Nó sẽ là SSH bỏ lỡ cấu hình ở cuối máy chủ. Tập tin sshd_config phía máy chủ phải được chỉnh sửa. Nằm trong /etc/ssh/sshd_config. Trong tệp đó, thay đổi biến

• 'có' thành 'không' đối với ChallengeResponseAuthentication, PasswordAuthentication, UsePAM

• 'không' thành 'có' cho PubkeyAuthentication

Dựa trên http://kaotickreation.com/2008/05/21/disable-ssh-password-authentication-for-added-security/

Đảm bảo rằng AuthorizedKeysFiletrỏ đến đúng vị trí, sử dụng %unhư một trình giữ chỗ cho tên người dùng:

# /etc/ssh/sshd_config
AuthorizedKeysFile /home/%u/authorized_keys

Nó có thể là bạn chỉ cần bỏ ghi chú dòng:

AuthorizedKeysFile .ssh / ủy quyền

Lưu ý rằng bạn phải tải lại dịch vụ ssh để thay đổi diễn ra:

service sshd reload

Hai ý kiến: điều này sẽ ghi đè lên tập tin gốc. Tôi chỉ cần sao chép khóa công khai được tạo và làm một cái gì đó như:

cat your_public_key.pub >> .ssh/authorized_keys

Điều này sẽ nối thêm khóa bạn muốn sử dụng vào danh sách các khóa có sẵn. Ngoài ra, một số hệ thống sử dụng tệp authorized_keys2, do đó, nên tạo một liên kết cứng trỏ giữa authorized_keysvà authorized_keys2, chỉ trong trường hợp.

Giải pháp của tôi là tài khoản đã bị khóa. Thông báo được tìm thấy trong / var / log / safe: Người dùng không được phép vì tài khoản bị khóa Giải pháp: cung cấp cho người dùng mật khẩu mới.

Tôi gặp vấn đề tương tự và làm theo các bước sử dụng chế độ gỡ lỗi.

/usr/sbin/sshd -d

Điều này cho thấy kết quả sau đây

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
Authentication refused: bad ownership or modes for directory /root
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: Could not open authorized keys '/root/.ssh/authorized_keys2': No such file or directory
debug1: restore_uid: 0/0
Failed publickey for root from 135.250.24.32 port 54553 ssh2
debug1: userauth-request for user root service ssh-connection method gssapi-with-mic

Nó thực sự khó hiểu

[root@sys-135 ~]# ls -l /
drwxrwxrwx.   2 root root     4096 Dec 14 20:05 bin
drwxrwxrwx.   5 root root     1024 May  6  2014 boot
drwxrwxrwx.   2 root root     4096 Dec  2  2013 cgroup
drwxrwxrwx.  10 root root     1024 Sep 25 23:46 data
drwxrwxrwx. 124 root root    12288 Dec 16 10:26 etc
drwxrwxrwx.  11 root root     4096 Jan 14  2014 lib
drwxrwxrwx.   9 root root    12288 Dec 14 20:05 lib64
drwxrwxrwx.   2 root root    16384 Jan 10  2014 lost+found
drwxrwxrwx.   2 root root     4096 Jun 28  2011 media
drwxr-xr-x.   2 root root        0 Dec 10 14:35 misc
drwxrwxrwx.   2 root root     4096 Jun 28  2011 mnt
drwxrwxrwx.   4 root root     4096 Nov 24 23:13 opt
dr-xr-xr-x. 580 root root        0 Dec 10 14:35 proc
drwxrwxrwx.  45 root root     4096 Dec 16 10:26 root

Nó cho thấy thư mục gốc có quyền cho mọi người. Chúng tôi đã thay đổi nó để những người khác sẽ không có quyền.

[root@sys-135 ~]# chmod 750 /root

Xác thực khóa bắt đầu làm việc.

Trong tập tin / etc / selinux / config thay đổi SELINUX thành vô hiệu hóa để thực thi ssh không mật khẩu đã làm việc thành công.

Trước đó tôi có thể làm điều đó trên một cách. Bây giờ từ cả hai chiều tôi có thể làm ssh không mật khẩu.

Một điều mà tôi đã sai là quyền sở hữu trên thư mục nhà của tôi trên hệ thống máy chủ. Hệ thống máy chủ được đặt thành mặc định: mặc định nên tôi:

chown -R root:root /root

Va no đa hoạt động. Một cách giải quyết khác giá rẻ là Vô hiệu hóa StrictModes: StirctModes no. trong sshd_config. Điều này ít nhất sẽ cho bạn biết nếu các giao thức trao đổi và kết nối khóa là tốt. Sau đó, bạn có thể đi săn các quyền xấu.

Đối với tôi, giải pháp này trái ngược với Wojtek Rzepala : Tôi không nhận thấy mình vẫn đang sử dụng authorized_keys2, thứ đã bị phản đối . Thiết lập ssh của tôi đã ngừng hoạt động tại một số điểm, có lẽ là khi máy chủ được cập nhật. Đổi tên .ssh/authorized_keys2như đã .ssh/authorized_keyssửa vấn đề.

Ôi!

Trước đây tôi đã bắt gặp một số hướng dẫn mô tả cách đạt được thiết lập không cần mật khẩu ssh, nhưng một số sai lầm đáng buồn.
Hãy bắt đầu lại và kiểm tra từng bước:

1. TỪ KHÁCH HÀNG - Tạo khóa: Khóa chung ssh-keygen -t rsa
   và khóa riêng ( id_rsa.pubvà id_rsa) sẽ được lưu tự động trong ~/.ssh/thư mục.
   Thiết lập sẽ dễ dàng hơn nếu bạn sử dụng cụm mật khẩu trống. Nếu bạn không sẵn sàng làm điều đó, thì vẫn làm theo hướng dẫn này, nhưng cũng kiểm tra điểm đạn bên dưới.
   
   
2. TỪ KHÁCH HÀNG - Sao chép khóa chung vào máy chủ : Khóa chung của máyssh-copy-id user@server
   khách sẽ được sao chép vào vị trí của máy chủ ~/.ssh/authorized_keys .
   
   
3. TỪ KHÁCH HÀNG - Kết nối với máy chủ:ssh user@server
   
   

Bây giờ, nếu nó vẫn không hoạt động sau 3 bước được mô tả, hãy thử các cách sau:

• Kiểm tra ~/sshquyền thư mục trong máy khách và máy chủ .
• Kiểm tra /etc/ssh/sshd_configtrong máy chủ để đảm bảo rằng RSAAuthentication, PubkeyAuthenticationvà UsePAMtùy chọn không bị khuyết tật, chúng có thể được kích hoạt theo mặc định với yes.
• Nếu bạn đã nhập cụm mật khẩu trong khi tạo khóa máy khách, thì bạn có thể thử ssh-agent& ssh-addđể đạt được các kết nối không cần mật khẩu trong phiên của mình.
• Kiểm tra nội dung /var/log/auth.logtrên máy chủ để tìm ra vấn đề tại sao xác thực khóa bị bỏ qua.

Tôi đã gặp vấn đề chính xác tương tự với PuTTY khi kết nối với máy Ubuntu 16.04. Thật khó hiểu vì chương trình pscp của PuTTY đã hoạt động tốt với cùng một khóa (và cùng một khóa hoạt động trong PuTTY để kết nối với máy chủ khác).

Nhờ nhận xét có giá trị từ @UtahJarhead, tôi đã kiểm tra tệp /var/log/auth.log của mình và tìm thấy như sau:

sshd[17278]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Hóa ra các phiên bản mới hơn của OpenSSH không chấp nhận các khóa DSA theo mặc định. Khi tôi chuyển từ DSA sang khóa RSA, nó hoạt động tốt.

Một cách tiếp cận khác: câu hỏi này thảo luận về cách định cấu hình máy chủ SSH để chấp nhận khóa DSA: https://superuser.com/questions/1016989/ssh-dsa-keys-no-longer-work-for-password-less-authentication?lq = 1

Những bước này sẽ giúp bạn ra ngoài. Tôi sử dụng điều này thường xuyên trong số nhiều máy Ubuntu 10.04 64 bit.

[ ! -f ~/.ssh/id_rsa.pub ] && ssh-keygen -t rsa;
ssh <username>@<remote_machine> 'mkdir -p ~/.ssh'
cat ~/.ssh/id_rsa.pub | ssh <username>@<remote_machine> 'cat >> ~/.ssh/authorized_keys'

bạn có thể đặt nó trong một kịch bản với một số lời nhắc và gọi nó là

script_name username remote_machine

Tôi đã có vấn đề tương tự với ssh. Trong trường hợp của tôi, vấn đề là tôi đã cài đặt hadoop cloudera (từ vòng / phút trên centos 6) và nó đã tạo ra các hdfs người dùng với thư mục chính

/var/lib/hadoop-hdfs(không chuẩn /home/hdfs).

Tôi đã thay đổi trong / etc / passwd /var/lib/hadoop-hdfsthành /home/hdfs, chuyển thư mục chính sang vị trí mới và bây giờ tôi có thể kết nối với xác thực khóa chung.

Tôi chỉ gặp vấn đề tương tự, và đối với tôi, giải pháp là đặt UsePAMra no. Xem, ngay cả khi PasswordAuthenticationđược đặt thành no, bạn vẫn sẽ nhận được keyboard-interactivevà trong trường hợp của tôi, chương trình ssh cục bộ của tôi tiếp tục mặc định như vậy, vì một số lý do.

Nền tảng bổ sung để giúp bất kỳ ai có cùng hoàn cảnh: Tôi đang kết nối từ máy chủ đang chạy Dropbear đến một máy đang chạy OpenSSH. Với PasswordAuthenticationvà UsePAMcả hai được đặt notrên máy từ xa, tôi sẽ nhận được thông báo sau nếu tôi nhập ssh user@server:

ssh: Connection to user@server:22 exited: Disconnect received

Cung cấp các tập tin nhận dạng với -i, mọi thứ hoạt động như mong đợi.

Có thể có thêm một chút thông tin ở đây.

Sau khi kiểm tra các quyền và thử một số giải pháp khác được liệt kê ở đây, cuối cùng tôi đã xóa thư mục ssh trên máy chủ, thiết lập lại khóa công khai của tôi.

Lệnh máy chủ:

# rm -rf ~/.ssh

Các lệnh cục bộ:

# ssh-copy-id user@192.168.1.1        # where <user> is your username and <192.168.1.1> is the server IP

Tại máy chủ:

$ ls -lh /home
$ sudo chmod 700 /home/$USER

Nó đã được directory permission issue. Đó là 777 tại máy chủ, vì vậy I changed it back to 700. Đây fixedlà vấn đề của tôi với ssh password less login failurengay cả sau khi sao chép $USER/.ssh/id_rsa.pubvào máy chủ $USER/.ssh/authorized_keys.

Tuy nhiên, một lựa chọn khác là một biến thể của câu trả lời của @Jagadish : cho stracedaemon ssh.

Nó có một lợi thế đáng kể, đó là chúng ta không cần phải dừng sshd, điều gì có thể dẫn đến việc khóa hoàn toàn nếu có vấn đề gì xảy ra.

Đầu tiên, chúng tôi tìm thấy pid của quá trình sshd chính. Ở đây chúng ta có thể thấy nó bằng cách thực hiện a pstree -pa|less.

  |-sshd,633 -D  <-- THIS IS WHAT WE WANT!
  |   `-sshd,21973   
  |       `-sshd,21996    
  |           `-bash,22000
  |               `-screen,638 -r

Sau khi biết, pid là 633, chúng ta có thể strace, theo con của nó:

strace -p 633 -s 4096 -f -o sux

Kết quả sẽ là mọi thứ mà sshd này và các tiến trình con của nó đã thực hiện sẽ được strace-ed vào tệp có tên suxtrong thư mục cục bộ.

Sau đó tái tạo vấn đề.

Nó sẽ có một danh sách lớn nhật ký cuộc gọi kernel, hầu hết không thể hiểu được / không liên quan đến chúng tôi, nhưng không phải ở đâu cũng có. Trong trường hợp của tôi, điều quan trọng là:

6834  sendto(4, "<38>Jan 15 18:49:21 sshd[6834]: User cica not allowed because account is locked\0", 84, MSG_NOSIGNAL, NULL, 0) = 84

Điều đó có nghĩa là, sshd đã cố gắng đăng nhập tin nhắn Người dùng cica không được phép vì tài khoản bị khóa - điều đó là không thể, bởi vì việc đăng nhập không đủ dài dòng cho điều đó. Nhưng chúng ta đã biết, pubkey đã bị từ chối vì tài khoản đã bị khóa.

Nó vẫn chưa phải là một giải pháp - bây giờ chúng ta cần google, nghĩa là "tài khoản bị khóa" trong trường hợp của sshd. Nó rất có thể là một số tầm thường /etc/passwd, /etc/shadowphù thủy, nhưng điều quan trọng đã được thực hiện - vấn đề không phải là một bí ẩn, mà là một vấn đề dễ bị gỡ lỗi / googlable.

Trong trường hợp của tôi, tôi có tất cả các quyền và ngay cả khi chạy ssh với cờ -vvv, tôi không thể tìm ra vấn đề là gì.

Vì vậy, tôi đã tạo chứng chỉ mới trên máy chủ từ xa

ssh-keygen -t rsa -C "your_email@example.com"

và sao chép các khóa được tạo vào máy cục bộ và thêm khóa công khai mới vào ~ / .ssh / ủy quyền trên máy chủ từ xa

cat id_rsa.pub >> authorized_keys

Sử dụng các phím được tạo từ kết nối máy chủ từ xa hiện hoạt động. Vì vậy, nếu các giải pháp khác thất bại thì đây là một điều khác để thử.

Kịch bản của tôi là tôi có một máy chủ NAS mà tôi đã tạo một backupbotngười dùng, sau khi tạo tài khoản chính của tôi, có thể đăng nhập để tạo backupbotngười dùng ban đầu . Sau khi đấu tranh sudo vim /etc/ssh/sshd_configvà tạo backupbotngười dùng, vimcó thể tạo, ít nhất là trên Ubuntu 16.04 và dựa trên ~/.vimrccấu hình của bạn , một tệp hoán đổi còn lại từ chỉnh sửa phiên vim của bạn /etc/ssh/sshd_config.

Kiểm tra xem nếu: /etc/ssh/.sshd_config.swptồn tại và nếu nó loại bỏ nó và khởi động lại sshddaemon:

$ sudo rm /etc/ssh/.sshd_config.swp
$ sudo service sshd restart

Điều này kỳ diệu giải quyết vấn đề của tôi. Trước đây tôi đã kiểm tra tất cả các quyền của mình và thậm chí dấu vân tay RSA của khóa công khai và khóa riêng. Điều này là lạ và có thể là một lỗi với sshd, cụ thể là phiên bản này:

OpenSSH_7.4p1 Ubuntu-10, OpenSSL 1.0.2g ngày 1 tháng 3 năm 2016