...
이 문서는 X 응용 프로그램이 Xmanager에 연결을 시도할 수 있는 가능한 모든 상황에 대해서 설명합니다.
그림 A
위의 그림 A에서 네 가지의 접속을 설명하고자 합니다. 오직 사례 ①만이 승인된 시도입니다. 사용자는 올바른 인증 정보를 가지고 있습니다. 사례 ②, ③ 그리고 ④의 경우는 승인되지 않은 시도입니다. 이것들은 사용자가 인식하지 못한 시도이거나 자신의 Xmanager에 접속하는 것을 원치 않는 시도입니다. 그림에서도 접속 시도가 차단된 것을 알 수 있습니다. 다른 원격 호스트에서 하는 접속 시도도 이러한 조건과 같습니다.
...
아래의 'test' 사용자는 Xmanager에서 SSH 프로토콜을 사용하여 접속한 사용자입니다. 이 사용자는 Xmanager의 SSH 모듈에서 생성한 쿠키 정보를 가지고 있습니다. test 계정이 실행한 Xclock은 올바른 쿠키로 SSH 서버의 로컬 포트에 연결을 시도했으므로 성공적으로 연결되었습니다. localhost:10.0은 아래의 ubuntu13-10 장비의 로컬 TCP 포트 6010을 나타냅니다.
사례 ② : 인증되지 않은 연결
아래의 'test2' 사용자는 Xmanager에서 접속한 사용자가 아닙니다. 이 사용자가 SSH 서버에 연결을 시도하지만 인증되지 않은 사용자입니다. Xclock이 SSH 서버의 로컬 포트에 연결을 시도했지만, 일치하지 않은 쿠키로 인해 올바르게 작동하지 않았습니다.
사례 ③ : 방화벽이 있는 일반적인 TCP 연결
...
사례 ③은 ubuntu13-10 장비의 로컬 바인딩이 아닌 외부 네트워크 포트 바인딩을 통해 Xmanager가 있는192.168.1.123의 0번 디스플레이(TCP 포트 6000)로 연결을 시도합니다. 이 연결은 SSH 터널이 아닌 직접적인 일반 TCP 연결입니다. 그러나 연결이 성립되기 전에 방화벽 시스템에 의해 차단됩니다.
이 사례는 인증 받은 사용자나 인증 받지 않은 사용자나 마찬가지 결과입니다. 방화벽이 X11 포트를 적극적으로 차단할 경우 인증되었거나 인증되지 않은 모든 X11 연결이 허용되지 않을 것입니다.
...
이 사례도 로컬 바인딩이 아닌 외부 포트 바인딩을 사용하여 Xmanager에 연결을 시도하는 직접적인 일반 TCP 연결입니다. 방화벽에 의해 차단되지 않았으므로 연결에 성공하였습니다. 그러나 Xmanager는 연결이 인증되지 않았음을 인식합니다. Xmanager의 접근 제어 기능은 다음과 같은 알림 창을 표시합니다. 192.168.1.115 장비는 예의 ubuntu13-10 장비입니다:
'아니요'를 선택할 경우 Xclock에 대한 패킷이 거부됩니다. 사례 ④도 사례 ③과 마찬가지로 사용자의 인증 여부와는 관련이 없습니다.
Xmanager는 호스트 접근 제어 기능을 기본값으로 켜 놓고 있고 실제로는 위 알림 메시지조차 내 보내지 않고 차단합니다.
...