SSH 비밀번호는 SOCKS 비밀번호가 아닙니다
OpenSSH 동적 리스너에서 SSH 로그인과 SOCKS 클라이언트 인증을 구분하십시오.
ssh -D 를 시작하려고 비밀번호를 입력했습니다. 그것은 SSH 연결을 인증했을 뿐입니다. 새 리스너에 도달할 수 있는 모든 프로그램에 대해 비밀번호로 보호된 SOCKS 계정을 만든 것은 아닙니다.
OpenSSH의 동적 전달은 인증된 SSH 전송 위에서 로컬 SOCKS 서비스를 제공합니다. SOCKS5 처리는 인증이 없는 방식을 선택합니다. 일반적인 SOCKS 사용자 이름/비밀번호 서버가 아닙니다.
개인 용도라면 로컬에 바인딩하십시오:
ssh -N -D 127.0.0.1:1080 [email protected]
그 컴퓨터의 애플리케이션은 SSH 비밀번호를 SOCKS 비밀번호로 입력하지 않고도 포트 1080을 사용합니다. 동적 전달 문서가 리스너를 설명하며, OpenSSH의 SOCKS 처리 소스가 인증 세부 정보를 제공합니다.
공유는 문제를 바꿉니다
LAN 주소에 바인딩하면 포트가 원래의 로컬 용도 너머로 도달 가능해집니다. 주변 클라이언트는 자신의 트래픽이 당신의 것을 거친다는 이유만으로 별도의 SSH 세션을 만들지 않습니다. 네트워크가 접근을 허용하면 그 클라이언트들은 게이트웨이의 외부 신원을 공유할 수 있습니다.
방화벽은 도달 가능한 클라이언트를 제한할 수 있지만 SOCKS 로그인 교환을 추가하지는 않습니다. 별도의 SOCKS 사용자 이름, 할당량 또는 사용자별 규칙이 필요하면 그러한 기능을 지원하는 서버를 선택하십시오. 예를 들어 Dante는 SOCKS 인증을 클라이언트 주소 제한과 별도로 문서화합니다.
문제 해결에도 도움이 됩니다. SOCKS 사용자 이름/비밀번호 방식을 고집하는 클라이언트는 이 리스너와 기대대로 협상하지 못할 수 있습니다. 애플리케이션을 조정하거나 적절한 인증 SOCKS 서비스를 선택하십시오. SSH 비밀번호를 반복해서 시도하는 것은 잘못된 로그인을 다루는 일입니다.
로컬 전용 도달성은 여전히 이해해야 할 경계이며, 로컬 컴퓨터의 모든 프로세스가 같은 사용자에게 속한다는 주장은 아닙니다.