Tôi đang cố gắng kết nối với Linode (chạy Ubuntu 12.04 LTS) từ máy cục bộ của tôi (cũng chạy Ubuntu 12.04 LTS)

Tôi đã tạo khóa riêng và khóa chung trên máy cục bộ của mình và sao chép khóa chung của mình vào tệp ủy quyền của Linode. Tuy nhiên, bất cứ khi nào tôi cố gắng ssh vào Linode của tôi, tôi nhận được thông báo lỗi Permission denied (publickey).

Đó không phải là vấn đề với cách ssh được thiết lập trên Linode của tôi bởi vì tôi có thể ssh đến nó từ máy Windows của mình bằng cách sử dụng xác thực khóa.

Trong .sshthư mục của tôi trên máy Ubuntu cục bộ, tôi có các tệp id_rsavà id_rsa.pubtệp của tôi . Tôi có cần tạo tệp ủy quyền trên máy cục bộ không?

EDIT: Đây là những gì tôi nhận được khi chạy ssh -vvv -i id_rsa [youruser]@[yourLinode]:

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: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

PubKeyAuthentication

Thiết lập khách hàng của bạn

1. Tạo chìa khóa của bạn
   • ssh-keygen
2. Cấu hình ssh để sử dụng phím
   • vim ~/.ssh/config
3. Sao chép khóa của bạn vào máy chủ của bạn
   • ssh-copy-id -i /path/to/key.pub SERVERNAME

Tệp cấu hình của bạn từ bước 2 sẽ có nội dung tương tự như sau:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Bạn có thể thêm IdentitiesOnly yesđể đảm bảo sshsử dụng IdentityFilevà không có các keyfiles khác trong khi xác thực, điều này có thể gây ra sự cố và không phải là một cách thực hành tốt.

Xử lý sự cố

1. sử dụng tùy chọn "-vvv"
2. Đảm bảo rằng máy chủ có khóa PUBLIC (.pub) của bạn.
3. Hãy chắc chắn rằng IdentiyFile của bạn trỏ đến khóa RIÊNG TƯ của bạn.
4. Đảm bảo thư mục .ssh của bạn có 700 và các tệp của bạn là 700 quyền (rwx ------).
5. tail -f /var/log/auth.log (trên máy chủ) và theo dõi lỗi khi bạn cố đăng nhập
6. Nếu bạn có nhiều tệp chính, hãy cố gắng IdentitiesOnly yesgiới hạn xác thực để sử dụng khóa đơn, được chỉ định.

Đôi khi vấn đề đến từ quyền và quyền sở hữu. Ví dụ, nếu bạn muốn đăng nhập như là người chủ, /root, .sshvà authorized_keysphải thuộc về root. Mặt khác, sshd sẽ không thể đọc chúng và do đó sẽ không thể biết liệu người dùng có được phép đăng nhập hay không.

Trong thư mục nhà của bạn:

chown -R your_user:your_user .ssh

Đối với quyền, đi với 700 cho .sshvà 600 choauthorized_keys

chmod 700 .ssh
chmod 600 .ssh/authorized_keys

Bạn không cần authorized_keystrên khách hàng của bạn.

Bạn phải yêu cầu ssh-client thực sự sử dụng khóa bạn đã tạo. Có một số cách để làm điều đó. Chỉ dành cho loại thử nghiệm ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode]. Bạn sẽ phải cung cấp cụm mật khẩu của mình mỗi lần bạn muốn kết nối với máy chủ.

Nếu mà làm việc bạn có thể thêm chìa khóa cho sự ssh-agentvới ssh-add .ssh/id_rsa(bạn sẽ phải cung cấp mật khẩu một lần duy nhất cho điều này và nó sẽ làm việc miễn là bạn không đăng xuất / khởi động lại)

Ngoài ra kiểm tra giá trị của PasswordAuthenticationtrong /etc/ssh/sshd_configvà nếu nó nothay đổi nó để yes. Đừng quên khởi động lại dịch vụ ssh sau đó.

Vấn đề tôi gặp phải là nó đã sử dụng sai phím trên máy khách. Tôi đã đổi tên id_rsa và id_rsa.pub thành tên khác. Bạn có thể đổi tên chúng trở lại mặc định hoặc khi bạn ban hành lệnh ssh, hãy sử dụng nó như thế này

ssh -i ~/.ssh/private_key username@host

Đồng thời đảm bảo rằng thư mục chính của người dùng (trên máy chủ) thực sự thuộc về người dùng ssh'ing vào (đã được đặt thành root: root trong trường hợp của tôi).

Đáng lẽ phải:

sudo chown username:username /home/username;

Tôi gặp vấn đề này gần đây với máy chủ web của tôi.

Tôi thường giữ một danh sách các khóa được ủy quyền trên tất cả các máy chủ của mình ~/.ssh/authorized_keys2. Từ kinh nghiệm của tôi, sshdsẽ tìm kiếm ~/.ssh/authorized_keyshoặc ~/.ssh/authorized_keys2theo mặc định.

Trong trường hợp máy chủ web của tôi, /etc/ssh/sshd_configdòng này có dòng này

AuthorizedKeysFile    %h/.ssh/authorized_keys

thay vì

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Tôi đã áp dụng cái sau, khởi động lại ssh daemon của tôi và giải quyết vấn đề của tôi khi đăng nhập bằng ssh bằng pubkey của tôi.

Một nguyên nhân có thể khác có thể là với AllowedUserscấu hình trong /etc/ssh/sshd_conf. Chú ý: danh sách là không gian được phân định (không Comma delimited) như tôi học được cách cứng.

AllowUsers user1 user2 user3

Nếu vẫn thất bại, hãy kiểm tra xem người dùng đăng nhập của bạn có thuộc Nhóm được phép của ssh không. Nghĩa là, người dùng của bạn là thành viên của nhóm được hiển thị ở dòng sau trong /etc/ssh/sshd_configmáy chủ:

AllowGroups ssh #Here only users of 'ssh' group can login

Tôi là trường hợp của tôi, máy khách là Ubuntu 14.04lts, máy chủ đã thắng máy chủ 2012 chạy cygwin. Tôi đã sử dụng 'ssh Administrator @ xxxx', khi thư mục máy chủ 2012 trong cygwin là / home / Administrator. Vì vậy, nó phân biệt chữ hoa chữ thường, khi tôi thử 'ssh Administrator @ xxxx' (lưu ý viết hoa A trên Administrator) thì nó hoạt động tốt.

Một thông báo lỗi như 'không tìm thấy người dùng' sẽ đưa tôi đến giải pháp nhanh hơn rất nhiều so với 'Quyền bị từ chối (khóa công khai, tương tác bàn phím)'.

Tôi gặp vấn đề tương tự khi sao chép khóa chung của người dùng thông thường (ví dụ johndoe) từ hệ thống cPanel Centos sang máy chủ Ubuntu trên AWS. Theo đề xuất của gertvdijk ở trên, tôi đã kiểm tra /var/log/auth.logvà chắc chắn rằng nó đã nói Authentication refused: bad ownership or modes for directory /home/johndoe. Hóa ra tôi đã nhầm 777 /home/johndoekhi cố gắng đặt /home/johndoe/public_htmllàm Root Document Document Virtualhost mặc định cho apache2 (điều đó cũng không cần thiết cho tác vụ đó).

Xem thêm câu trả lời ở đây và đây

Máy chủ chỉ cần có khóa chung .ssh/authorized_keysvà máy khách (máy tính bạn đang làm việc) cần có khóa riêng (.pem hoặc nếu sử dụng SFTP với Filezilla, .ppk)

Đối với những người dùng Putty như tôi đã đến với chủ đề này, bạn cũng có thể gặp lỗi này nếu bạn quên thêm người dùng @ Ip!

Những người khác được phép trên tệp chính chmod tới 600)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).`

ssh user@1.1.1.1 -i /path/to/.pem file 

Đây là những gì làm việc cho tôi, sửa chữa không phải là của tôi nhưng tôi muốn viết nó ra đây trong trường hợp người khác có cùng một vấn đề.

Tác giả ban đầu đã đăng nó ở đây: kỹ thuật số-đại dương-truy cập-khóa-bị từ chối

sudo nano /etc/ssh/sshd_config

Thay thế cái này

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Với cái này

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Lưu tệp và khởi động lại ssh

reload ssh

ssh nên làm việc bây giờ yêu cầu mật khẩu

Tôi đã có cùng một vấn đề như được mô tả trong câu hỏi. Đầu ra từ việc thực thi ssh -vvv -i id_rsa [youruser]@[yourLinode]trên máy khách tương tự như được mô tả trong câu hỏi. Tôi đã kiểm tra tất cả các quyền của tập tin và thư mục như được khuyên trong các câu trả lời khác, và chúng đã đúng.

Hóa ra khi sao chép tệp được tạo id_rsa.pubvào máy chủ, dưới dạng tệp ~username/.ssh/authorized_keys, tôi đã vô tình bỏ sót từ này ssh-rsangay từ đầu. Thêm nó đã giải quyết vấn đề.

Hoạt động trên Ubuntu 16.04 là tốt.

Vấn đề là trong sshd_configtập tin

Đây là giải pháp ULTIMATE:

Đăng nhập với tư cách là root cho máy chủ Ubuntu của bạn

vi /etc/ssh/sshd_config

Bây giờ đi đến tận cùng và thay đổi giá trị từ "không" thành "có".

Nó sẽ giống như thế này:

Thay đổi thành không để vô hiệu hóa mật khẩu văn bản rõ ràng được điều chỉnh

PasswordAuthentication yes
service sshd reload

có hiệu lực.

Bây giờ bạn có thể chỉ cần một phím bằng cách sử dụng lệnh sau từ máy LOCAL (còn gọi là máy tính xách tay, v.v.)

Vì vậy, hãy mở cửa sổ terminal mới và KHÔNG đăng nhập vào máy chủ, chỉ cần đặt lệnh này:

ssh-copy-id john @ serverIPĐịa chỉ

(Thay thế john bằng tên người dùng của bạn).

bạn nên đi

Một số người thắc mắc có thể đã thiết lập quyền truy cập ssh chỉ là khóa trên tài khoản root sau đó tạo một người dùng mới và không nhận ra họ cần phải

ssh root@your-ip-address

rsync --archive --chown=[user]:[user] ~/.ssh /home/[user]

logout

Sau đó thử lại. Thay thế [người dùng] bằng tài khoản người dùng mới của bạn.

Điều này phổ biến khi thiết lập máy chủ mới trên DigitalOcean khi bạn đã sử dụng các phím ssh khi thiết lập.

https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ub Ubuntu-18-04

Trong trường hợp của tôi, vấn đề là do sao chép một .sshthư mục từ một máy cũ hơn. Hóa ra cấu hình SSH cũ hơn của tôi đã sử dụng các khóa DSA đã bị từ chối . Chuyển sang một cặp khóa mới, lần này dựa trên RSA, đã giải quyết vấn đề cho tôi.

Phương pháp sau đây có thể hoạt động nếu bạn có thể truy cập machineA và machineB một cách độc lập (ví dụ: từ machineC).

Nếu ssh-copy-id không hoạt động, xác thực mật khẩu có thể bị tắt. Sau đây là một cách giải quyết .

Có khóa công khai của machineA trong các khóa được ủy quyền của machineB (ví dụ ~ / .ssh / ủy quyền) sẽ cho phép bạn ssh từ machineA. Điều này cũng áp dụng cho scp.

Sau khi tạo các cặp khóa bằng cách sử dụng: ssh-keygen

Trên máyA , thực thicat ~/.ssh/id_rsa.pub

Đầu ra mẫu:

ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA

Sao chép khóa được in ( ⌘ Command+ Choặc CRTL+ C) sau đó thêm nó vào tệp ~ / .ssh / ủy quyền trên máyB .

Ví dụ, thực hiện các thao tác sau trên machineB :

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB anask@mahineA' >> ~/.ssh/authorized_keys