및가 포함된 두 개의 arch linux
가상 머신 debian
(에서 실행 중 )이 있습니다 . virtual box
얼마 전부터 .NET을 통해 VM에 연결하는 데 arch
많은 시간이 걸리기 시작했습니다 ssh
. 처음에는 잠시 후 연속적인 시도가 빠르게 이루어집니다. arch
가상 머신에서 본 내용 은 다음과 같습니다 .
debug1: userauth-request for user yuri service ssh-connection method none
debug1: attempt 0 failures 0
debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line
debug2: parse_server_config: config reprocess config len 314
debug2: input_userauth_request: setting up authctxt for yuri
debug1: PAM: initializing for "yuri"
debug1: PAM: setting PAM_RHOST to "10.0.2.2"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
Failed none for yuri from 10.0.2.2 port 35786 ssh2
10.0.2.2
가상 머신의 기본 게이트웨이입니다. 무슨 뜻이에요?
PS 이것은좋은 대답, 덕분에 이 문제를 연구하는 데 어느 정도 진전을 이룰 수 있었습니다.
답변1
내 생각 엔 문제는 DNS 요청 시간 초과입니다. 연결하려는 서버에서 UseDNS 옵션을 꺼보세요.
서버 로그를 보면 이 사실이 거의 확인됩니다(게시하길 잘하셨습니다 :).
debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line
보고 man sshd_config
:
UseDNS Specifies whether sshd(8) should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address. The default is “yes”.
이는거의 의미가 없다. 꼭 확인하세요아니요연결을 종료합니다. 통과하지 못하면 손가락 흔들기 메시지만 기록됩니다.
7월 9일 05:43:00 brick sshd[18971]: 주소 200.41.233.234는 host234.advance.com.ar에 매핑되지만 이는 해당 주소로 다시 매핑되지 않습니다. 침입 시도가 가능합니다!
이는 무능한 ISP를 사용하는 사용자에게 끔찍한 오탐지를 생성할 뿐입니다.
좋습니다. 그러면 이것이 어떻게 지연을 초래할 수 있습니까?
DNS 서버가 즉시 응답하지 않으면 클라이언트는 기다렸다가 다시 시도하는 경향이 있습니다. (네트워크 정체로 인해 DNS 패킷이 지연되거나 손실되는 경우) DNS 서버가 전혀 응답하지 않으면 클라이언트는 결국 포기하게 됩니다. 예를 들어 dig
내 시스템에서는 재시도 시간이 15초입니다. (더 구체적인 DNS 라이브러리 코드를 사용하지만 원리는 동일합니다.)
$ time dig invalid @192.0.2.1
; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> invalid @192.0.2.1
;; global options: +cmd
;; connection timed out; no servers could be reached
real 0m15.020s
user 0m0.010s
sys 0m0.011s
따라서 문제는 역방향 조회가 응답을 받지 못한다는 것입니다. 서버에서 직접 동일한 조회를 수동으로 실행할 수 있으며 SSH와 동일한 대기 시간이 표시되어야 합니다. getent hosts 10.0.2.2
.
답변2
이 단계에서 연결 속도가 느려지는 원인은 여러 가지가 있습니다. ~에서이것제가 본 문제 중 하나인 Link는 암호화와 관련이 있었습니다.
마침내 문제가 무엇인지 알아냈습니다.
내 /home/user 디렉토리는 암호화되어 있으므로 로그인하지 않으면 ssh가 해당 디렉토리에 액세스할 수 없습니다.
또 다른 가능성은 다음에서 비롯됩니다.여기서비스 관련 SELinux
.
네,
SELinux
그게 이유일 수도 있어요. 디렉토리.ssh
의 레이블이 잘못 지정되었을 수 있습니다. 보다/var/log/audit/audit.log
. 로 표시되어야 합니다ssh_home_t
. 확인하십시오.ls -laZ
필요한 경우 실행하십시오restorecon -r -vv /root/.ssh
.
또한이것링크를 통해 PAM 인증이 SSH 속도 저하의 원인이 될 수 있다는 점도 확인했습니다.
'를 수정하세요./etc/ssh/ssh_config"를 입력하고 다음 줄을 주석 처리합니다.
GSSAPIAuthentication yes GSSAPIDelegateCredentials no