ssh mật khẩu không hoạt động


35

Tôi đã cố gắng để thiết lập một mật khẩu ít ssh b / w Ađể BBđể Alà tốt. Tạo khóa chung và khóa riêng bằng ssh-keygen -trsacả hai máy. Sử dụng các ssh-copy-idtiện ích để sao chép các công chìa khóa từ Ađể Bcũng như Bđể A.

Ssh không mật khẩu hoạt động từ Ađến Bnhưng nottừ Bđến A. Tôi đã kiểm tra các quyền của thư mục ~ / ssh / và dường như là bình thường.

A's .ssh quyền thư mục:

-rw-------  1 root root 13530 2011-07-26 23:00 known_hosts
-rw-------  1 root root   403 2011-07-27 00:35 id_rsa.pub
-rw-------  1 root root  1675 2011-07-27 00:35 id_rsa
-rw-------  1 root root   799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root  4096 2011-07-27 00:37 ..
drwx------  2 root root  4096 2011-07-27 00:38 .

B's .ssh quyền thư mục:

-rw------- 1 root root  884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root  396 2011-07-27 00:15 id_rsa.pub
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .

Alà một Ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubfox4, OpenSSL 0.9.8k 25/03/2009) Blà một máy debian (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g ngày 19 tháng 10 năm 2007)

Từ A:

#ssh B

hoạt động tốt

Từ B:

#ssh -vvv A 
...
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,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: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@192.168.122.1's password: 

Điều đó có nghĩa là nó không xác thực bằng cách sử dụng tệp /root/id_rsa. Tôi chạy ssh-addlệnh trong cả hai máy là tốt.

Phần xác thực của /etc/ssh/sshd_configtệp là

# 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

Tôi đang cạn kiệt ý tưởng. Bất kỳ trợ giúp sẽ được đánh giá cao.


Các thiết lập của là gì PermitRootLogintrong /etc/ssh/sshd_configtrên A?
taneli

@taneli : yes, nếu không, người dùng sẽ không được nhắc nhập mật khẩu.
Lekensteyn

Trong trường hợp của tôi, tôi đã bỏ ghi chú "IgnoreUserKnownhosts yes" trong tệp "/ etc / ssh / sshd_config" trên
ubfox

Câu trả lời:


24

Chỉ cần đảm bảo rằng bạn đã làm theo quy trình sau:

Trên máy A

mở một thiết bị đầu cuối và nhập các lệnh như sau:

root@aneesh-pc:~# id

Chỉ để đảm bảo rằng chúng tôi đã root.

Nếu lệnh trên xuất ra một cái gì đó như bên dưới, chúng ta sẽ chuyển sang root bằng cách sử dụng sulệnh

uid=0(root) gid=0(root) groups=0(root)

1) Tạo các phím.

ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
49:7d:30:7d:67:db:58:51:42:75:78:9c:06:e1:0c:8d root@aneesh-pc
The key's randomart image is:
+--[ RSA 2048]----+
|          ooo+==B|
|         . E=.o+B|
|        . . .+.*o|
|       . . .  ...|
|        S        |
|                 |
|                 |
|                 |
|                 |
+-----------------+

Tôi chưa sử dụng bất kỳ cụm mật khẩu nào. Nếu bạn cần một cái bạn có thể sử dụng nó.

2) Sao chép khóa chung vào .ssh/authorized_keystệp của máy B

root@aneesh-pc:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@mylap
root@mylap's password: 

Bây giờ hãy thử đăng nhập vào máy, với ssh 'root@mylap'và kiểm tra:

~/.ssh/authorized_keys

để đảm bảo chúng tôi chưa thêm các khóa bổ sung mà bạn không mong đợi.

Thay thế mylap bằng tên máy chủ hoặc ip của máy bạn muốn đăng nhập (tức là máy B)

3) Đăng nhập vào B mà không cần mật khẩu

root@aneesh-pc:~# ssh root@mylap
Warning: Permanently added 'mylap,192.168.1.200' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/

Last login: Wed Jul 27 15:23:58 2011 from streaming-desktop.local
aneesh@mylap:~$

Trên máy B

4) Tạo các phím để đăng nhập lại vào Máy A

root@mylap:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
35:9f:e7:81:ed:02:f9:fd:ad:ef:08:c6:4e:19:76:b1 root@streaming-desktop
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|          o   .  |
|         . + + o |
|        S o * E  |
|           = O . |
|            O +  |
|           + o o.|
|            . o+=|
+-----------------+

5) Sao chép khóa chung vào .ssh/authorized_keystập tin của máy A

root@mylap:~# ssh-copy-id -i /root/.ssh/id_rsa.pub root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
root@aneesh-pc's password: 

Bây giờ hãy thử đăng nhập vào máy, với ssh 'root@aneesh-pc'và kiểm tra:

.ssh/authorized_keys

để đảm bảo chúng tôi chưa thêm các khóa bổ sung mà bạn không mong đợi.

6) Đăng nhập vào A mà không cần mật khẩu

ssh root@aneesh-pc
Warning: Permanently added 'aneesh-pc,192.168.1.20' (RSA) to the list of known hosts.
Welcome to Ubuntu 11.04 (GNU/Linux 2.6.38-8-generic x86_64)

 * Documentation:  https://help.ubuntu.com/


Last login: Tue Jul 26 18:52:55 2011 from 192.168.1.116

Nếu bạn có thể hoàn thành các bước này Bạn đã hoàn thành. Bây giờ bạn có hai máy có đăng nhập kích hoạt ssh-key (khóa công khai).


đã thực hiện tất cả 6 bước như đã chỉ định, xác minh tất cả những điều liên quan đến bước 5, nhưng bằng cách nào đó, bước 6 không hoạt động
Cuquil

Bạn có thể cung cấp đầu ra của lệnh này: 'ssh -v root @ aneesh-pc'. thay thế tên người dùng và tên máy chủ bằng tên của bạn
aneeshep

15
phát hiện ra thủ phạm là quyền của /root(770) drwxrwx--- 70 root root 4096 2011-07-27 00:37 .. quá mở. Đã thay đổi quyền drwxr-xr-xvà bây giờ nó đang hoạt động. Không thể tưởng tượng được sự thật rằng sự cho phép của thư mục mẹ ảnh hưởng đến ssh.
Cuquil

1
@Cupered Bắt tốt, thư mục nhà của tôi cũng đã được 770đặt, đã thay đổi thành a 750và tất cả đều đúng với thế giới :) Tôi dường như luôn quên rằng prems linux có thể hoạt động ngược lại như thế.
phàn nàn

1
Lỗi ở bước 3. ssh-copy-id chạy sau khi tôi nhập mật khẩu, tuy nhiên tôi vẫn không thể đăng nhập mà không được nhắc nhập mật khẩu, tệp ủy quyền của tôi chứa văn bản .pub của tôi và tôi đang cung cấp khóa khi đăng nhập . Không có kết quả. Quyền trên tất cả các thư mục là chính xác.
Matt Clark

44

Sau khi thiết lập ssh không có mật khẩu , tôi vẫn được hỏi mật khẩu người dùng. Nhìn /var/log/auth.logvào máy từ xa chỉ ra vấn đề:

sshd[4215]: Authentication refused: bad ownership or modes for directory /home/<user>

Vì vậy, hãy chắc chắn rằng nó có đúng:

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

Mặc dù việc cấm người dùng khác viết lên .sshthư mục của bạn là điều hiển nhiên, nhưng có cùng yêu cầu đối với thư mục nhà của bạn lại khó khăn hơn.

Ngoài ra, kiểm tra /etc/ssh/ssd_configđể đảm bảo rằng RSAAuthenticationPubkeyAuthenticationtùy chọn là không khuyết tật. Mặc định là yeskhông nên là một vấn đề.


cũng đảm bảo rằng các thư mục được liệt kê ở trên được sở hữu bởi người dùng chính xác
GoalBasing

Tôi đã rơi vào tình huống này bằng cách gỡ bỏ một kho lưu trữ trình điều khiển realtek được tạo ra tồi tệ. Nó đã thay đổi chủ sở hữu trên thư mục tôi đã gỡ bỏ nó vào.
Paul McMillan

2
Thư mục nhà của bạn không thể ghi được vì nếu có, thì tôi có thể đổi tên của bạn ~/.sshthành thứ khác, rồi tạo một cái mới với khóa riêng của tôi trong đó.
Kevin Panko

2
tuyệt vời! đã không nghĩ về việc tìm kiếm các bản ghi trên máy chủ. Cảm ơn!
dùng3099609

14

Có lẽ chỉ là một vấn đề quyền cấp cao hơn. Bạn cần xóa quyền ghi khỏi nhóm và khác vào thư mục chính và thư mục .ssh. Để sửa các quyền này, hãy chạy chmod 755 ~ ~/.sshhoặc chmod go-w ~ ~/.ssh.

Nếu bạn vẫn gặp sự cố, hãy đưa ra grep sau trên nhật ký của bạn:

sudo egrep -i 'ssh.*LOCAL_USER_NAME' /var/log/secure

(thay thế LOCAL_USER_NAMEbằng tên người dùng địa phương của bạn ...)

Điều đó hy vọng sẽ cho bạn biết thêm về vấn đề của bạn, giả sử thông tin xác thực sshd đang được ghi vào nhật ký bảo mật, theo mặc định. Nếu bạn thấy lỗi giống như thế này:

DATE HOSTNAME sshd [1317]: Từ chối xác thực: quyền sở hữu hoặc chế độ xấu cho thư mục / đường dẫn / đến / some / thư mục

Đó là vấn đề được mô tả ở trên và bạn cần tìm thư mục đang đề cập và xóa quyền ghi khỏi nhóm và các quyền khác.

Vì lý do là bạn sẽ cần hạn chế quyền ghi vào thư mục chính của mình (mặc dù quyền đã bị hạn chế trên .ssh và các thư mục tiếp theo), nó sẽ cho phép người dùng khác đổi tên thư mục .ssh của bạn và tạo một thư mục mới - mặc dù điều đó sẽ không thể sử dụng được (do quyền sai), cách khắc phục đối với hầu hết người dùng có thể là thay đổi quyền chứ không phải kiểm tra nội dung của thư mục ...

TLDNR : Cho phép truy cập ghi cho nhóm và / hoặc khác vào thư mục chính của bạn sẽ khiến ssh buộc đăng nhập mật khẩu.


2

bạn đang sử dụng tài khoản root trên mỗi máy? Thông thường trên Ubuntu, bạn sẽ sử dụng tài khoản người dùng và cấp cho nó quyền sudo theo yêu cầu.

Nếu bạn sử dụng một người dùng không root sudo chown $USER -R ~/.sshcó thể khắc phục vấn đề của bạn

Những thứ khác để kiểm tra:

kiểm tra kỹ xem B's id_rsa.pubcó ở A không authorized_keys.

kiểm tra A /etc/ssh/sshd_configchứa

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes

À, tôi đã kích hoạt tài khoản root trong máy Ubuntu, do đó chạy như một người dùng root trong cả hai hệ thống
Cuquil

Vâng tôi đã tìm ra, thêm một vài gợi ý khác mà bạn có thể đã bỏ qua. Đầu ra đó thực sự vô dụng mặc dù không phải vậy, không có lý do tại sao rsa không được chấp nhận.
Smithamax

1
bạn đúng là lý do tại sao khóa rsa không được chấp nhận là yếu tố thiết yếu ở đây tôi đoán :). sshd_config chứa các yếu tố đã nói ở trên, tôi đã chỉnh sửa câu hỏi để kết hợp nội dung của /etc/ssh/sshd_confignội dung tệp
Cuquil

-3

trong / etc / ssh / sshd_config khi thay đổi mục tiêu

PermitRootLogin không

đến

PermitRootLogin có

sau đó giết -HUP PID sshd của bạn:

root @ dzone2 # ps -ef | grep ssh root 28075 27576 0 ngày 17 tháng 11? 6:11 / usr / lib / ssh / sshd

root 17708 20618   0 10:09:30 pts/37      0:00 grep ssh root@dzone2 # kill -HUP 28075 root@dzone2 # ps -ef|grep ssh
root 17861 20618   0 10:09:44 pts/37      0:00 grep ssh
root 17852 27576   0 10:09:42 ?           0:00 /usr/lib/ssh/sshd

1
Điều này sẽ không giúp đỡ. Vấn đề là đăng nhập SSH không mật khẩu (xác thực bằng cặp khóa RSA) không hoạt động. Các hướng dẫn bạn đã cung cấp là để làm cho rootđăng nhập SSH hoạt động. Điều đó hoàn toàn không liên quan đến những gì câu hỏi này là về. Hơn nữa, nếu roottài khoản được bật (theo mặc định trong Ubuntu), việc bật rootđăng nhập SSH có thể khá nguy hiểm.
Eliah Kagan
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.