Tại sao chuyển tiếp đại lý ssh không hoạt động?


57

Trong máy tính của riêng tôi, chạy MacOSX, tôi có cái này trong ~ / .ssh / config

Host *
ForwardAgent yes
Host b1
ForwardAgent yes

b1 là một máy ảo chạy Ubuntu 12.04. Tôi ssh với nó như thế này:

ssh pupeno@b1

và tôi đã đăng nhập mà không bị yêu cầu nhập mật khẩu vì tôi đã sao chép khóa công khai của mình. Do chuyển tiếp, tôi có thể chuyển ssh sang Pupeno @ b1 từ b1 và nó sẽ hoạt động mà không cần hỏi tôi mật khẩu, nhưng không được. Nó hỏi tôi mật khẩu.

Tôi đang thiếu gì?

Đây là đầu ra dài dòng của ssh thứ hai:

pupeno@b1:~$ ssh -v pupeno@b1
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to b1 [127.0.1.1] port 22.
debug1: Connection established.
debug1: identity file /home/pupeno/.ssh/id_rsa type -1
debug1: identity file /home/pupeno/.ssh/id_rsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_dsa type -1
debug1: identity file /home/pupeno/.ssh/id_dsa-cert type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa type -1
debug1: identity file /home/pupeno/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 35:c0:7f:24:43:06:df:a0:bc:a7:34:4b:da:ff:66:eb
debug1: Host 'b1' is known and matches the ECDSA host key.
debug1: Found key in /home/pupeno/.ssh/known_hosts:1
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pupeno/.ssh/id_rsa
debug1: Trying private key: /home/pupeno/.ssh/id_dsa
debug1: Trying private key: /home/pupeno/.ssh/id_ecdsa
debug1: Next authentication method: password
pupeno@b1's password:

Câu trả lời:


94

Hóa ra chìa khóa của tôi không có trong đại lý và điều này đã sửa nó:

HĐH X :

ssh-add -K

Linux / Unix :

ssh-add -k

Bạn có thể liệt kê các khóa được tải bằng cách sử dụng:

ssh-add -l

ssh-add -L # for more detail

5
Lưu ý đó ssh-add -Klà dành riêng cho OS X.
Roger Lipscombe

Bạn có phải làm điều này mỗi lần khởi động lại không?
Krauser

8
  1. Kiểm tra xem các ./ssh/id_rsa .ssh/id_dsa .ssh/id_ecdsatệp của bạn có quyền chính xác mà người dùng của bạn sở hữu hay không và được mã hóa 600.

  2. Kiểm tra xem bạn có khóa công khai chính xác pupeno/.ssh/authorized_keystrên b1 không và kiểm tra xem authorized_keyscó ngắt dòng ở cuối khóa không.

  3. Kiểm tra xem bạn có chạy ssh-agent không, thử tải các phím qua ssh-add

  4. Hãy thử xác thực và chuyển tiếp dựa trên GSSAPI với ssh -K


Sự cho phép của các khóa là tốt và khóa trong ủy quyền là ổn (nếu không tôi nghĩ rằng tôi sẽ gặp khó khăn khi kết nối ở nơi đầu tiên).
Pupeno

Bạn đã chạy ssh-agent? Điều gì xảy ra khi bạn thực hiện một ssh-add rồi ssh -A Pupeno @ b1 và sau đó ssh Pupeno @ b1?
Daniel Prata Almeida

Tại sao bạn không cập nhật câu trả lời để đề cập đến ssh-add -K và tôi sẽ chấp nhận của bạn thay vì của tôi (vì thông tin được đăng gần như đồng thời).
Pupeno

6

Tôi gặp vấn đề với máy chủ sshd từ chối yêu cầu chuyển tiếp đại lý vì không còn chỗ trống trong / tmp. Điều này là do sshd cần tạo socket trong / tmp. Dọn dẹp đĩa giải quyết vấn đề của tôi.

ssh -v nói lại rồi:

debug1: Remote: Agent forwarding disabled: mkdtemp() failed: No space left on device

1
Tôi gặp vấn đề tương tự, chỉ có quyền là sai trên / tmp. CẢM ƠN!!
nevyn

6

Một lý do khác có thể là chia sẻ kết nối: một người có thể đã đăng nhập vào máy chủ khác mà không bật chuyển tiếp tác nhân và chia sẻ kết nối. Đăng nhập thứ hai với ssh -A(hoặc được chỉ định tương đương trong tệp cấu hình) thông qua kết nối được chia sẻ sẽ âm thầm bỏ qua -Acờ. Chỉ sau khi đăng xuất hoàn toàn hoặc vô hiệu hóa chia sẻ kết nối để đăng nhập lần thứ hai, chuyển tiếp tác nhân sẽ hoạt động.


2

Vì lợi ích của các nhân viên khác, những người cũng đến với câu hỏi này:

Khoảng trắng không chính xác trong tệp ~ / .ssh / config cũng có thể gây ra một số vết xước đầu.

Gần đây tôi đã giúp một trong những đồng nghiệp của mình, người đã có điều này:

# incorrect
host foobar ForwardAgent yes

thay vì điều này:

# correct
host foobar
  ForwardAgent yes

Tôi cũng đã chạy vào các trường hợp thiếu thụt dòng lệnh trong danh sách các máy chủ tạo ra sự khác biệt về chức năng, mặc dù điều đó không được phép.


0

Thêm các dòng sau vào tập tin .ssh / config

  Host **Server_Address**
     ForwardAgent yes

Thêm khóa vào Đại lý SSH

 ssh-add -K

Kết nối với máy chủ từ xa

ssh -v **username**@**Server_Address**

Chạy kiểm tra kết nối với GitHub

ssh -T git@github.com

Chạy ls kiểm tra từ xa đối với kho git được nhắm mục tiêu

git ls-remote --heads git@github.com:**account**/**repo**.git
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.