 |
|
난이도 : 초급 David Mertz 박사, 프로그래머/작가, Gnosis Software, Inc.
2001 년 12 월 01 일 Secure shell (SSH)과 Virtual Network Computing (VNC)을 여러 각도에서 비교한다. 두 기술 모두 사용자가 하나의 워크스테이션에서 다른 컴퓨터에 있는 애플리케이션을 실행할 수 있도록 하는 기술이다. (파일 및 프린트 공유나 httpd, ftpd, smtp, nntpd와 같은 인터넷 서비스는 다루지는 않을 것이다.) SSH와 VNC를 설치하고 설정하는 팁을 비롯하여 툴 안정성, 툴 선택, 라이센스 등에 관해 설명한다.
다양한 소프트웨어 프로그램을 효율적으로 작성하고 테스트하기 위해서, 내 로컬 네트워크상에는 상당히 많은 컴퓨터들이 있다.
이러한 머신들은 다양한 오퍼레이팅 시스템을 구동하고 있고 다양한 범위의 하드웨어 설정이 되어있다. 가끔씩 다양한 플랫폼상에서
툴을 평가하기도 한다; 직접 작성한 툴을 테스트하고 디버깅 한다.
네트워크 상의 머신들 대부분은 멀티 부팅 설정으로 다중 오퍼레이팅 시스템이 설치되어 있다. 이 중 많은 것은 "headless"
이다. (모니터나 키보드가 없다). VMWare, Plex86, VirtualPC, SheepShaver 등과 같은 하나의 오퍼레이팅
시스템을 가상화(virtualize)하는 툴은 평가하지 않았다. 어떤 부분에서는 그러한 툴들은 이 글에서 논하려는 것과 비슷한
목적을 수행할 것이다.
다양한 기술들로 인해서 한 워크스테이션의 사용자가 다른 컴퓨터의 애플리케이션을 구동할 수 있다. SSH는 원격 컴퓨터에 텍스트
터미널을 제공한다; X Window System은 실제로 실행되는 곳과는 다른 워크스테이션 상에 대화식의 애플리케이션을 디스플레이
하는 데 사용될 수 있다; VNC는 전체 원격 데스크탑에 대해 "리모콘" 역할을 수행한다. 각 기술에는 장단점이
있다. 그들은 모두 리눅스에서 실행되고 다양한 OS환경과 상호작용이 가능하다. 이러한 툴들을 사용하여 나는 한 워크스테이션(최상의
모니터, 키보드, 의자를 갖추고 있다!)에 앉아서 많은 플랫폼상의 애플리케이션들을 실행하고 테스트하며 시간을 재고 있다. 어떤
것도 재부팅 할 필요가 없다.
나만의 네트워크 설정
나의 로컬 네트워크에는 7개의 노드가 있다. 각자 Apollo, Bacchus, Chaos, Delphi, Echo, Fury,
Gaia라는 이름을 붙였다. 이 노드들은 각각 192.168.1.101에서 192.168.1.107까지의 IP 어드레스도 갖고
있다. 물리적으로 같은 머신은 같은 IP 어드레스를 가지고 있다. (가끔씩 DHCP를 사용하는 데 이것은 192.168.1.200
이상의 어드레스를 할당한다). 모두 하드웨어 방화벽/라우터 뒤에 배치되었다. 나는 방화벽을 충분히 신뢰한다. (인터넷을 통해
컴퓨터를 공유해야 하는 독자들이라면 보안에 좀 더 주의를 기울여야 한다. 다음 글에는 보안 문제에 대해서 다루겠다).
앞으로 설명할 쉘 예제를 쉽게 따라올 수 있도록 지금까지 자세한 설명을 했다. 실제로 내가 앉아있는 머신은 Bacchus
이고 로컬 IP 어드레스는 192.168.1.102 이다.
Secure shell (ssh)
컴퓨터를 연결하는 대역 친화적인 방식 대부분은 간단한 테스트 쉘을 통한 것이다. 이 같은 비 보안 (Non-secure) 툴로는
telnet과 rsh 등이 있다. 하지만 이들을 사용할 때 많은 보안상의 문제들이
발생한다. 차라리 통신을 해야 한다면 컴퓨터에 ssh를 설치하는 것이 낫다. 많은 유닉스 계열 오퍼레이팅
시스템(리눅스 포함)들은 디폴트로 ssh가 설치되어 있다. 설치되어 있지 않다면, 참고자료에
설치 방법이 소개되어 있다.
Secure shell (ssh)은 특정 채널을 통해 오는 모든 트래픽을 암호화 한다. 공개 키 암호가
사용되기 때문에 서버와 클라이언트가 세션 초기화에 앞서 키를 공유할 필요가 없다. 게다가 채널을 통해서는 암호화 되지 않은 어떤
'비밀'도 전송되지 않는다. VNC 또는 X Window 같은 다른 프로토콜들은 ssh의 상단에 놓일
수 있다. 원격 테스트 콘솔을 만드는 데 가장 간단하게 사용될 수 있다.
ssh를 사용하면 로컬 머신상의 다른 오퍼레이팅 시스템으로 쉽게 연결 할 수 있다. 이때, 원격 머신이
sshd 서버를 실행하고, 로컬 머신이 ssh 클라이언트를 실행해야 한다. 예를
들어 OS/2 Warp "Bacchus" 머신을 Slackware Linux "Delphi" 머신으로 연결할 경우, 다음과 같이
할 수 있다:
ssh를 이용하여 HOSTS 이름으로 원격 박스에 연결하기
C:\UTILS % ssh quilty@delphi
Last login: Thu Nov 29 01:41:36 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ exit
logout
Connection to delphi closed. |
HOSTS 파일이 앨리어스(alias)를 정의하지 않았다면 다음과 같이 한다:
ssh를 이용하여 IP로 원격 박스에 연결하기
C:\UTILS % ssh quilty@192.168.1.104
Last login: Thu Nov 29 01:51:31 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ |
이와 마찬가지로 나는 임대한 웹서버를 다음을 사용하여 관리한다:
ssh를 이용하여 DNS 이름으로 원격 박스에 연결하기
C:\UTILS % ssh gnosis@gnosis.cx
gnosis@gnosis.cx's password: |
이종 플랫폼 상에서 ssh와 관련된 가장 어려운 점은 올바른 터미널 설정이다. 문제는 ssh
자체의 문제가 아니다. 두 개의 리눅스 머신을 함께 연결하는 것은 별 문제없이 수행된다. 하지만 클라이언트 또는 서버로서 개입된
다른 플랫폼이 있을 때, 디스플레이가 정확하게 되지 않거나 키 바인딩이 예상했던 대로 수행되지 않는다. Win32, BeOS,
MacOS, OS/2 같은 비 유닉스 계열 플랫폼이 개입되면 문제는 특히 심각해진다. 심지어 리눅스와 FreeBSD를 연결할
때도 완벽하지 않다.
이종 머신들 간에 ssh 연결을 할 때 발생하는 가장 일반적인 문제들은 코드페이지(codepage)가
틀리거나 "color escape code"들이 틀리다는 것이다. 둘 중 한 문제가 발행하면 기본 명령어 라인을
사용할 수 있다. 종종 컬러가 아닌 단색의 터미널 만이 보이게 된다. 쉘 명령어는 이러한 "impedance mismatch"으로
인한 문제가 없지만 대화형 curses 또는 slang 타입의 애플리케이션은 많은
문제를 겪는다. 그와 같은 애플리케이션 중 가장 주목할 것은 텍스트 에디터이다. 이것은 대부분 원격 콘솔을 통해 실행해야 하는
애플리케이션이다. jed 는 특별히 훌륭한 원격 텍스트 모드 에디터이다; 강심장을 가진 사람들은 아마도
vim을 사용할 것이다. 다른 대부분의 리눅스/유닉스 에디터는 X 기반이거나 전체적으로 조잡했다.
만일 터미널 설정 문제가 있다면 몇 가지 방법이 있다. 유닉스 계열의 sshd 서버로 연결한다면 원격
TERM 환경 변수를 변경해보라:
대중적인 원격 터미널 세팅
quilty@delphi:~$ TERM=vt100
quilty@delphi:~$ TERM=ansi
quilty@delphi:~$ TERM=linux |
로컬 ssh 클라이언트는 터미널 타입의 연결을 설정하는 데에 보통 한 가지 방법을 가지고 있다. 플랫폼과
클라이언트 프로그램에 따라, 명령행 옵션이나 환경 변수 또는 메뉴창이 될 수 있다. 두 끝단에서 이름이 똑같은 것으로 끝나지
않을 수도 있다. 여기에는 몇 가지 에러가 있다. 또한 클라이언트 설정 범위내에서 "no codepage translation"을
사용하고 있는지를 확인해야 한다. "impedance match"를 테스트하려면 "fullscreen remote application"
(jed 또는 기타 에디터)을 실행해보라.
Virtual Network Computing (VNC)
VNC는 많은 GUI 플랫폼에 포팅되고 있는 클라이언트/서버 시스템이다. VNC는 로컬 시스템상의 원격 컴퓨터의 전체 "데스크탑"을
디스플레이 하는 데에 사용되는 프로토콜을 제공한다. Symantec의 pcAnywhere는 같은 용도로 쓰이는 상용
제품이다. 하지만 Microsoft 오퍼레이팅 시스템에만 제한되어 있다. 반면, VNC는 수십 개의 다른 오퍼레이팅 시스템상에서
실행되며 많은 구현과 "variation"들이 있다.
웹사이트 (참고자료)에서 스크린샷을 참조하는 것도 VNC를 이해하는데 도움이
된다. 일반적으로, VNC 클라이언트 (vncviewer)를 가지고 있는 모든 플랫폼은
로컬 윈도우 범위 내에서 VNC 서버 (vncviewer)를 가진 모든 플랫폼의 가상 데스크탑을 디스플레이
할 수 있다. VNC 클라이언트 버전에 따라, 리사이징(resizing)과 fullscreen 옵션 등을 사용할 수 있다.
X-based 버전의 VNC 서버 (Xvnc)와 다른 플랫폼용 서버 사이에는 약간의 차이점이 있다.
Windows, MacOS, BeOS, OS/2 같은 단일 유저 시스템은 X Window System의 수행방식인 "desktop
sessions" 개념이 없다. 따라서 Windows VNC 서버는 로컬 시스템상에 나타나는 같은 Windows 데스크탑의 원격
버전만을 디스플레이 한다; 이것은 연결할 때 "desktop :0" 으로 호출된다. 반면 X Window는 멀티 유저/멀티 세션이다.
각각의 Xvnc 세션은 새로운 데스크탑을 만들고 고유의 해상도, 윈도우 매니저, 상태(state)등을
만든다. 다시말해서, X는 VNC 보다 훨씬 더 훌륭하다.
일단 VNC가 설치되면 세션을 시작하는 것은 간단하다. (참고자료). 단일 유저
플랫폼의 경우, 기본적으로 애플리케이션은 실행할 수 있다. 어떤 옵션도 없다. X 에서, 몇 가지 명령행 옵션들은 유용하다.
OS/2 Warp "Bacchus" 로컬 머신에서 Mandrake Linux "Fury" 머신까지 telnet
세션을 연결한 예를 보자:
Fury에서 VNC 서버 세션 시작
[root@fury quilty]# cat /usr/bin/vnc-sessions
vncserver -name TinyLinux -depth 8 -geometry 640x480
vncserver -name BigLinux -depth 32 -geometry 1260x940
[root@fury quilty]# vnc-sessions
New 'TinyLinux' desktop is fury.gnosis.lan:1
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:1.log
New 'BigLinux' desktop is fury.gnosis.lan:2
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:2.log |
클라이언트 측에서 로컬 vncviewer를 사용하여, Fury:1 또는 Fury:2
로 연결 할 수 있다 (또는 한 번에 양쪽 모두 가능). 또한 192.168.1.106:1 을 지정할
수 있었다.
같은 원리가 "non-local" 네트워크에도 적용되며 VNC는 보안 용도로 SSH를 통해 터널로 설정될
수 있다.
대부분의 경우, vncviewer를 원격 컴퓨터에 연결하는 것은 기능상으로 볼 때 그 원격 컴퓨터에
대해 (이것이 headless가 아니라는 것을 가정할 때) 로컬 모니터와 키보드 앞에 앉아 있는 것과 같다. 심미안적으로 볼
때 원격 시스템의 데스크탑은 로컬 머신의 위젯을 사용하여 윈도우에 의해 짜여질것이다. (fullscreen 옵션을 사용하지 않는
한). 이러한 가외의 프레임은 언뜻 보기에는 산만하게 보이지만 조금 사용하다 보면 무뎌진다.
올바른 세션 지오메트리(geometry)와 색상 깊이를 선택하는 것은 중요하다. 원격 데스크탑이 작을 수록 그리고 사용된
컬러 수가 적을 수록, 디스플레이 반응은 좀 더 빨라진다. 컬러 깊이를 줄이는 것이 반응에 약간의 영향을 미친다는 것을 발견했다;
VNC의 hextile 인코딩은 스크린의 세련되지 못한 "pixel-by-pixel" 전송 보다 훨씬 더 효율적이다.
하지만 스크린 사이즈는 분명한 차이를 보인다.
일반적으로, 위의 1260x940과 같은 원격 지오메트리를 사용하면 1280x1024 비디오 세팅으로 매우 훌륭히 작동한다.
나는 약간의 여유 공간을 두어 VNC titlebar와 로컬 데스크탑의 taskbar를 위한 공간으로 허용했다. 하지만 vncviewer
윈도우는 여전히 전체 스크린 대부분을 차지하고 있다. 그런대로 괜찮다. 100 Mbit 이더넷 연결을
할 때 로컬 디스플레이 보다 나쁘지 않다. 10 Mbit 이더넷 상에서, 윈도우를 옮기거나 사이즈를 조절할 때 미세한 디스플레이를
보게 된다. 좀 더 느린 속도로는 VNC가 원격 작동에 대한 최적의 솔루션이 되지 않는 경향을 보인다. Cable, DSL,
T1 연결 또한 완벽하게 작동한다. 이 보다 작은 것은 비상용(emergency)으로만 쓰인다.
VNC 연결에 있어서 한 가지 문제점은 로컬 데스크탑은 고유의 목적에 맞춰 몇 가지 키스트로크를 이용해야 한다. 특정 클라이언트에
따라, 많은 원격 키스트로크가 다중 키스트로크 작동으로 에뮬리에트 되어야 한다. 예를 들어, 나의 로컬 OS/2 vncviewer의
경우 원격 Alt-F 를 입력하기 위해서는 Alt-A, F, Alt-A 를 눌러야
한다. 가외의 스트로크들은 가끔씩 조절하기가 힘들다. Macs 같이 고유의 키보드와 (원버튼) 마우스를 가지고 있는 "non-PC"
플랫폼에서 상황은 훨씬 더 복잡해진다. 더 많이 공부해야 겠지만 일반적으로 원격 인풋 액션을 에뮬레이팅하는 방법이 있다. 리눅스에서
리눅스로의 연결은 부드럽게 작동한다.
주목할 만한 VNC 구현이라 한다면 Java 버전일 것이다. 고유의 vncviewer 없는 플랫폼에도
Java 버전을 사용할 수 있다. (JVM이 플랫폼을 위해 존재한다고 가정할 때). VNC-java는 웹 브라우저 내에서 실행될
수 있다. 연결에 필요한 익숙한 인터페이스를 제공한다. 하지만 Java viewer는 브라우저 밖에서는 Java 애플리케이션
처럼 작동할 수 있다. 참고자료 에서 VNC-java에 대한 정보를 얻기 바란다.
다음에는..
Part 2 에서는, remote X와 네트워크를 통해 원격 애플리케이션을 실행하는 다른 방법들을 설명할 것이다. 또한 원격
애플리케이션을 사용할 때의 보안 문제에 대해서도 다룰 것이다.
참고자료
- developerWorks worldwide 사이트에서 이 기사에 관한 영어원문.
- 상용 공식 버전의 SSH : SSH Communications
Security 제공. 비 상업적 용도로 무료로 사용할 수 있지만 Free Software는 아니다.
- 대부분의 리눅스 배포판은 OpenSSH
를 사용한다.
- FreSSH : 기존 코드에 대한 의존성을
피하기 위해 SSH 프로토콜을 재구현 한 것.
- FreeSSH 사이트: (FreSSH와 혼동하지
말것) 무료/상용 SSH 구현 정보 제공.
- Windows의 경우, Free (MIT 라이센스) Software 프로그램인
PuTTY 를 권한다. 설치가 쉽다.
- BeOS와 OS/2의 경우, 각각 BeBits.com과
Hobbes OS/2 archive를 참조하기 바란다.
VNC 참고자료
VNC 참고자료
기타 참고자료
- David Mertz의 developerWorks 튜토리얼:
필자소개 | | | David Mertz 박사 has authored this article |
기사에 대한 평가
|
| 이 문서 북마킹 하기
|
| 
