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

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 đề như vậy 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 2222 trên máy chủ (yêu cầu đầy đủ đường dẫn đến sshd thực thi, which sshd có thể giúp) và sau đó kết nối từ máy khách với ssh -p 2222 [email protected]. Đ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 cổng thay thế, bạn có thể tạm thời dừng trình nền SSH và thay thế bằng cổng ở 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 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.service thay thế.)

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 Của mình sang 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 thư mục /etc/ssh/username, Được sở hữu bởi tên người dùng, với các quyền chính xác và đặt tệp authorized_keys Vào đó. Sau đó, đã thay đổi lệnh AuthorizedKeysFile trong /etc/ssh/config Thà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_keys bạ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 [email protected]_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 [email protected]_address

   Bây giờ bạn sẽ 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.

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 [email protected]

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: [email protected]                                          
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 người dùng @ myclient. Khi một khóa được mặc định, không có kiểm tra tên máy khách.

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 trên 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

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

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 ở /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 AuthorizedKeysFile trỏ đến đúng vị trí, sử dụng %u với tư cách là người 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

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

[[email protected] ~]# 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.

[[email protected] ~]# chmod 750 /root

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

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.

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, vì vậy, nên tạo một liên kết cứng trỏ giữa authorized_keys và authorized_keys2, chỉ trong trường hợp.

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.

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.

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: ssh-keygen -t rsa
   [.__.] Khóa công khai và riêng tư (id_rsa.pub và id_rsa) sẽ được lưu trữ tự động trong ~/.ssh/ danh 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ủ: ssh-copy-id [email protected]
   [.__.] Khóa công khai của máy 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 [email protected]
   
   

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 ~/ssh quyền thư mục trong máy khách và máy chủ máy.
• Kiểm tra /etc/ssh/sshd_config trong máy chủ để đảm bảo rằng các tùy chọn RSAAuthentication, PubkeyAuthentication và UsePAM không bị tắt, chúng có thể được bậ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 ứng dụng khách của mình, thì bạn có thể thử ssh-agent & ssh-add để đạt được kết nối không cần mật khẩu trong phiên của bạn.
• Kiểm tra nội dung của /var/log/auth.log trên máy chủ để tìm vấn đề tại sao xác thực khóa bị bỏ qua.

Đối với tôi, giải pháp hoàn toàn ngược lại Wojtek Rzepala's : Tôi không nhận thấy mình vẫn đang sử dụng authorized_keys2, mà đã 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_keys2 như .ssh/authorized_keys đã khắc phục sự cố.

Ôi!

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ột 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]

Nó chỉ ra rằng 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 -Thông tin? lq = 1

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 [email protected]        # where <user> is your username and <192.168.1.1> is the server IP

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-hdfs đến /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 máy chủ:

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

Đó là directory permission issue. Đó là 777 tại máy chủ, vì vậy I changed it back to 700. Điều này fixed vấn đề của tôi với ssh password less login failure ngay cả sau khi sao chép $USER/.ssh/id_rsa.pub đến máy chủ $USER/.ssh/authorized_keys.

Tôi cũng gặp vấn đề tương tự và đối với tôi, giải pháp là đặt UsePAM thành no. Xem, ngay cả với PasswordAuthentication được đặt thành no, bạn vẫn sẽ nhận được keyboard-interactive, và 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 chủ đang chạy OpenSSH. Với PasswordAuthentication và UsePAM cả hai đều đặt no trên máy từ xa, tôi sẽ nhận được thông báo sau nếu tôi nhập ssh [email protected]:

ssh: Connection to [email protected]:22 exited: Disconnect received

Cung cấp tệp 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.

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

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 người dùng backupbot, sau khi tạo tài khoản chính của tôi, có thể đăng nhập để tạo ban đầu backupbot user. Sau khi đấu với Sudo vim /etc/ssh/sshd_config và tạo người dùng backupbot, vim có thể tạo, ít nhất là trên Ubuntu 16.04 và dựa trên ~/.vimrc Cấu hình, một tệp hoán đổi còn lại từ chỉnh sửa /etc/ssh/sshd_config Của phiên vim của bạn.

Kiểm tra xem liệu: /etc/ssh/.sshd_config.swp Có tồn tại không và nếu nó xóa nó và khởi động lại sshd daemon:

$ 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

Tuy nhiên, một tùy chọn khác là một biến thể của @Jagadish 's answer : to strace dash 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 một 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 nó, theo dõi các con của nó:

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

Kết quả sẽ là mọi thứ những gì sshd này và các quy trình con của nó đã thực hiện, sẽ được strace-ed vào tệp có tên sux trong thư mục địa phương.

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 - chỉ không thể, vì đăng nhập là 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/shadow Wizardry, 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 "[email protected]"

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ử.