SSH 인증을위한 LDAP 을이용한 SSH 키의설계및구현 김수홍상명대학교컴퓨터소프트웨어공학전공김성기서울대학교대학원컴퓨터공학과 The Design and Implementation of SSH Keys using LDAP for SSH Authentication Soo-Hong Kim Major in Computer Software Engineering, Sangmyung University SeongKi Kim Dep't of Computer Engineering, Graduate School, Seoul National University 요약베어울프환경에서 SSH 인증을위한사용자및호스트키는모든시스템에서거의동일한정보이지만, 각시스템에서분산되어관리되기때문에관리의어려움이크다. 본논문에서는 LDAP 을이용하여 SSH 키를효율적으로관리하는시스템을설계하고구현하였다. 키워드 : SSH, LDAP, 베어울프 Abstract Both the user keys and the host keys which are used for SSH authentication are almost same each system in Beowulf environment, but it is difficult to manage keys because they are distributed to each system. This paper designed and implemented the system which manages efficiently the SSH keys using LDAP. Key Words: SSH, LDAP, Beowulf 1. 서론베어울프시스템 [1] 은수십에서수천대의마이크로시스템과이더넷으로구성되며, 저사양의 PC들을활용하며비용면에서저렴하고안정적인리눅스운영체제가사용되며특정한병렬작업에집중되어작업을수행한다. 베어울프시스템은수십, 수천의시스템들로구성되기때문에, 그관리가매우어렵다. 관리를위한소프트웨어들로는 bwatch[2], SCMS[3] 등이있는데, 이들소프트웨어들은모두그기반으로써 RSH나 SSH (Secure Shell)[4] 등을사용하며, 사용자들이직접관리나병렬프로그램의시작을위해 RSH, SSH 를사용한다. RSH은간편하고빠르다는장점이있는반면보안에취약하기때문에주로글로벌 (global) 환경보다는상대적으로보안에대한위협이적은로컬 (local) 네트워크내에서사용된다. SSH는로컬네트워크는물론글로벌네트워크환경에서도보안에대한걱정없이사용될수있다. 그러나 SSH는 RSH에비해느리며, 베어울프시스템내의다른노드로이동할때마다인증을하는불편없이자동적인인증을하기위해 SSH 키가필요한데이키들을관리하는것은노드가많아지고사용자가많아짐에따라점점복잡해지게된다. SSH 키는호스트키와, 사용자키로구분되고, 각키는공용키와사적키의쌍으로이루어진다. 베어울프시스템내에서모든호스트는자기자신의공용키와사적키는물론, 다른호스트들의공용키와경우에따라사용자들의공용키와비밀키를가지고있다. 각호스트의비밀키를제외한모든키들은서로공유되어관리되는것이편리하지만그렇지못한경우기존의대부분의베어울프환경에사용자가추가 / 삭제되는경우환경에존재하는모든노드마다사용자를추가 / 삭제하는반복적인관리작업이요구된다. 또한노드를추가 / 삭제 - 1 -
하는경우에는역시추가 / 삭제된노드를인지하기위해모든노드마다해당노드를파일에서추가 / 삭제하는작업이필요하다. 위와같이베어울프환경에서 SSH를사용할때보안을유지하면서자동으로인증하기위한키관리의어려움을해결하기위해본논문에서는키들의중앙저장장소로써 LDAP (lightweight directory access protocol)[5][6] 을사용하였으며 SSH 인증과관련된키들을중앙집중적으로관리하는 SSH 시스템을설계하고, 구현하였다. 본논문의 2장에서는 SSH와 LDAP을살펴보고 3장에서는 SSH 자동인증을위한 LDAP 과 SSH의새로운구조를기술하고, 4장에서는 3장에서기술한내용을바탕으로 LDAP의스키마설계와 SSH의구현에대해설명한다. 그리고 5장에서는결론을내려보기로한다. 2. SSH과 LDAP 이번장에서는 LDAP을사용해서 SSH 인증을하기위한구조를살펴보기전에 SSH와 LDAP을살펴보기로하겠다. 2.1 SSH SSH 는일반 RSH 프로그램들이 IP 기반으로인증을행하기때문에 IP 스푸핑 [7] 에취약하다는보안상의문제점을서버와클라이언트사이의암호화된통신을통해해결하고있다. SSH 를베어울프와같은환경에서다른노드로작업을이동해가면서작업하려할때인증방법이필요한데패스워드를입력해야하는불편함없이인증하기위해서는패스워드인증외에다른인증방법이필요하다. 이방법은 2 단계에걸쳐인증이일어나는데, 첫번째는서버의인증이고, 두번째는사용자의인증이다. 서버의인증은서버호스트를확인하는과정으로, 서버호스트를인증하기위해서는클라이언트는미리서버호스트의공유키를가지고있어야하므로베어울프클러스터내의모든호스트들은다른호스트들의공유키들을가져야하고그에따른관리의문제가있다. 사용자인증은세가지방법중의하나를선택하는것이가능하다. 다음절에서각각의인증에대해좀더자세히살펴보도록하겠다. 2.1.1 서버인증첫번째로서버호스트에대한인증을행하는단계인데다음과같은과정을거쳐세션키를만든다. Reques t Connect i on Ser v er Send Hos t Key, Ser v er Key Cl i ent Send Ses s i on Key < 그림 1> SSH 에서서버의인증 < 그림 1> 은서버의인증을보여주는것이다. 가장처음에클라이언트는서버에게로연결을요청하고서버는 SSH 를설치할때 - 2 -
생성된서버의호스트공용키와재생성되는서버키를보낸다. 클라이언트는서버가보낸호스트공용키를검증해본후, 저장하고임의의숫자를생성한후, 서버에게받은호스트공용키와서버키를이용해서임의의숫자를생성해서두개의키를사용하여암호화한후보내게된다. 이때, 이두번암호화된숫자를서버는사적키를이용해해독한후해독한숫자는세션키가되어서버와클라이언트의연결동안주고받는데이터를암호화시키는키로써사용되게된다. 따라서, 이때부터는만약중간에어떤다른시스템이서버와클라이언트사이에통신되는내용을본다고해도세션키를모르기때문에안전하다. 2.1.2 사용자인증사용자인증은다음처럼세가지방법중하나를선택해사용하는것이가능하다. 가장첫번째방법은단순히 rsh 의경우처럼, Trusted 호스트들을특정파일에써줌으로써아무런사용자의인증작업이필요없이로그인을가능하게해줄수가있다. ( 이경우는 rsh 과비슷하게연결을요청하는클라이언트의 IP 만가지고인증을수행한다.) 이방법은 IP 만가지고인증을행하기때문에, IP 스푸핑의위험이상당히존재한다. 그러므로이방법에대해서는이논문에서는논외로한다. 두번째방법은, 연결을시도하는클라이언트의키가서버의특정파일안에추가되어있고, 또한클라이언트의 IP 주소를역시서버안에저장해둠으로써, 역시로그인이가능해지게된다. 이방법은서버인증에서클라이언트는정말서버가맞는지를확인하고, 두번째단계인사용자인증단계에서사용자를확인하는것이아니라정말클라이언트가맞는지를클라이언트가보낸호스트공용키와호스트사적키를사용하여확인하는방법이며, 클라이언트를확인하는방식은, 역시클라이언트가서버를확인하는과정과유사하다. 먼저, 클라이언트는서버에게로클라이언트의호스트공용키를보내고, 서버는클라이언트가보낸호스트공용키를검증하고, 일치하지않는다면연결을거부하며, 만약일치한다면, 이클라이언트의호스트공용키를사용하여임의의숫자를생성하고, 암호화하여클라이언트에게로되돌려보내며, 클라이언트는호스트사적키를사용하여서버가생성해낸임의의숫자를풀어보고 MD5 해쉬값을계산해서서버로되돌려보낸다. 서버는이 MD5 해쉬값을이전에생성한임의의숫자값의 MD5 해쉬값과같은지확인해본후, 일치한다면인증은성공하게된다. 세번째방법은좀더보안이강화된방법으로, 사용자인증작업을수행하기위해 < 그림 2> 과같은작업을수행한다. Send Us er s Publ i c Key P Ser v er Send N Encr y pt ed wi t h P Decr y pt ed wi t h Pr i v at e Key and Send MD5 Has h Of N Cl i ent < 그림 2> SSH 에서사용자에대한인증 < 그림 2> 는사용자의인증방법을보여주는것인데, 클라이언트는서버에게사용자에대한공용키 P 를보내주고, 서버는받은 P 를가지고해당사용자의키가맞는지를검증해본후임의의숫자 N 을생성해서클라이언트에게서받은사용자에대한공용키를통해암호화한후, 클라이언트에게되돌려보낸다. 이때클라이언트는사용자에대한사적키를가지고, 암 - 3 -
호화된 N 을풀고 N 의 MD5 해쉬값을사용하여되돌려보낸다. 서버는클라이언트가보낸 MD5 해쉬값을보고맞으면, 사용자에대한인증이끝나게된다.[8][9] 즉, 사용자인증방법중두번째방법이클라이언트호스트에대한확인방법이라고한다면세번째방법은클라이언트호스트에대한확인이아니라사용자에대해서확인해보는방법이라고할수가있다. 2.2 LDAP LDAP 이란디렉터리서비스를위한프로토콜이다. 디렉터리서비스란, 엔트리들의관리와검색의편리성을위해하나의디렉터리안에여러개의엔트리들을저장하고, 이를권한을가진사용자가검색하고, 갱신하는등의작업을제공해주는서비스를말한다. 디렉터리서비스의디렉터리와엔트리들의구조는 < 그림 3> 과같이계층적인구조로이루어져있다. c = u s Di r e c t o r y o = x y z E n t r y E n t r y o = k r E n t r y A t t r A t t r A t t r T y p e V a l u e V a l u e < 그림 3> 디렉터리서비스의계층구조 위와같은계층구조를정의하기위해 LDAP 에서는스키마를사용하는데, 스키마에는디렉터리안에나타날수있는엔트리들과엔트리안에존재할수있는어트리뷰트의타입들을정의한다. 하나의엔트리를표현하기위해서 RDN(Relative Distinguished Name) 과 DN(Distinguished Name) 을사용하는데, RDN 이란하나의디렉터리의이름을나타내는데, 위의그림과같은상황에서는 c=us 와 o=xyz 등등이하나의 RDN 이되고, DN 이란이러한 RDN 들이모여서하나의 DN 을이루게된다. 그리고, 전체디렉터리구조에서하나의디렉터리를식별하기위해서는순차적으로 RDN 들을나열하게된다. 위의그림에서 RDN 이 o=xyz 인디렉터리를나타내는 DN 은 o=xyz, c=us 가되게된다. 디렉터리서비스를제공하기위해서는디렉터리서비스를제공해주는서버와디렉터리서비스를사용하려는클라이언트사이에통신작업이필요한데, 이러한통신을위한프로토콜이 LDAP 이며이전의 X.500 의축소판이다. 디렉터리서비스안에서저장된각종엔트리들은각종쓰기작업보다는읽기작업이더욱더많기때문에, 읽기에알맞게최적화되어있다. LDAP 자체에는네트워크패킷이중간에스니퍼링 (sniffering) 을통해가로채질위험성이존재한다. 이러한위험성을방지하기위해서 TLS[10] 를사용하는 LDAP 등이연구되고있다. 2.2.1 LDAP 을사용한인증 - 4 -
다. LDAP 을사용하여인증을처리하는과정은 < 그림 4> 와같은순서로일어나게된 L D A P S e r v e r R e q u e s t U s e r I D, P a s s w o r d R e s p o n s e R e q u e s t C o n n e c t i o n N o d e 1 N o d e 2 N o d e 3 N o d e 4 R e s p o n s e C o n n e c t i o n < 그림 4> LDAP 을사용한인증 < 그림 4> 과같이노드 1 에서노드 2 로로그인을요청시노드 2 는요청한사용자를인증하기위해노드 2 안에존재하는암호파일을참조하는것이아니라, LDAP 서버안에저장된엔트리의어트리뷰트를사용한다. 위와같은 LDAP 을사용한인증은 PAM[11] 을사용해서이루어지게된다. 2.2 NIS(Network Information System) 위에서언급한 LDAP 을인증을위한키들의중앙저장장소로사용하는경우, 암호파일을외부로노출시킴으로써비슷한목적으로사용가능한 NIS 가존재한다. 그런데, NIS 대신에 LDAP 을통해인증작업을수행하는것은 LDAP 에서는특정한 IP 뿐만이아니라특정한사용자에게 LDAP 검색을제공하는보안능력역시가지고있어서특정한사용자가본인에게만허용되어있는어트리뷰트에접근하는것이가능하다. 2.3 NFS(Network File System) 원래 NFS 는위와같이계정을중앙에서관리하거나공용키를한곳에모아둘용도로만들어진것은아니지만, NFS 를사용하여서도마치중앙에서계정을관리하는것처럼보이게만들수는있다. 암호파일을따로파일서버에저장해두고, 나머지노드들은이파일서버에저장된암호파일을접근하여사용하는것은가능하기때문에, 역시계정의중앙인증목적으로사용하는것이가능하다. 그러나 NFS 역시키의관리능력이없으며베어울프환경에서노드들이크게추가되어중앙파일서버로경쟁이심해질수있기때문에여기서는 NFS 를고려하지않았다. 3. 구조 SSH 의키들은크게두가지종류로구분되어질수있는데하나는호스트들의공용키와사적키, 다른하나의종류는사용자들의공용키와사적키가된다. 이러한키들중에서호스트의사적키를제외한나머지키들을 LDAP 에저장해서자동인증에사용하기위한 SSH 의구조를이번장에서는설명한다. - 5 -
먼저이후에나오는모든내용에서 LDAP 서버는신뢰할수있고 LDAP 서버와의통신은안전하다고가정한다. 이러한가정은 [10] 등을통해이루어질수있다. 3.1 LDAP 을사용한서버인증서버호스트인증을위한호스트들의공용키를 LDAP 을통해중앙집중적으로관리하는방법으로써 < 그림 5> 와같이동작한다. L D A P S e r v e r R e q u e s t N o d e 2 s P u b l i c H o s t K e y R e s p o n s e N o d e 2 s P u b l i c H o s t K e y R e q u e s t S S H N o d e 1 N o d e 2 N o d e 3 N o d e 4 R e s p o n s e S S H < 그림 5> LDAP 서버에서해당노드의공용키를가져오는과정 < 그림 5> 에서 Node 1이 Node 2로연결을요청하면 Node 2는서버의공용키를찾아서 Node 1으로전송하는데 Node 1은기존의방법처럼파일에서접속하려는서버호스트의공용키를읽으려고시도하고, 저장되어있지않은경우 LDAP 서버에호스트에대한공용키를요청하여읽어와서 Node 2가보낸공용키를검증한다. 공용키가일치하는경우연결은허용되어기존의 SSH처럼 Node 1은임의의수를생성하는등의세션키를만드는작업을수행한다. 이때 LDAP 서버에호스트의사적키는저장하지않았는데이것은노드의호스트사적키는모든노드가공통되게알아야될필요가없고, 만약호스트사적키까지저장한다면, 사적키의특성상오직루트만이이사적키에접근할수있도록설정해야되는데, 이렇게함으로써, SSH에서어떤노드에접근하려고할때마다노드의사적키를가져오기위해서호스트의사적키를생성할때사용한패스프레이스와루트의 DN의암호까지입력해주어야하는데, 이것은인증을편하게하려는처음의목적에위배된다. 따라서, 여기서는사적키는저장하지않았고, 만약사적키까지 LDAP 서버에저장하고자한다면, SSH로접속하려고할때마다패스프레이스와루트의 DN의암호를물어보아야한다. 즉 LDAP에호스트의사적키를저장하고오직루트만이해당호스트의사적키를읽을수있게설정해놓았기때문에루트의패스워드를입력하여호스트의사적키를가져와야하고가져온사적키를검증하기위해처음 SSH를설치할때입력한패스프레이스를입력해야한다. 사용자인증의세번째방법을사용하고자할때도이와동일한문제가발생하지만이경우는 SSHAGENT라는프로그램이존재하여위와같은문제를해결하여준다. 3.2 LDAP 을사용한사용자인증사용자인증방법중첫번째방법은별도로하고두번째방법은클라이언트호스트를확인하기위하여사용자의별도인증을갖지않고이미설명한서버의인증과유사하게다른서버에대한공유키가필요한경우 LDAP 서버에요청하여공유키를읽는방법을 - 6 -
사용한다. 그리고어떤호스트로부터의요청을허가할것인지를기술하는파일 (/etc/hosts.equiv) 도 LDAP 을통해중앙집중적으로관리하여관리문제를해결한다. 이두번째방법을사용할때의구조는다음과같다. L DA P S e r v e r R e q u e s t N o d e 1 P u b l i c Ho s t K e y R e s p o n s e N o d e 1 s P u b l i c Ho s t K e y No d e 1 No d e 2 No d e 3 No d e 4 < 그림 6> LDAP 서버에서해당클라이언트노드의공용키를가져오는과정 < 그림 6> 에서 Node 1 과 Node 2 사이에는서버인증이종료되어 < 그림 6> 처럼 Node 1 과 Node 2 사이에는세션키에의해보호된다. 이후, Node 1 이자신의공용키를 Node 2 로보내고 Node 2 는 Node 1 의호스트공용키를검증하기위해먼저파일에서검색한후존재하지않는경우 LDAP 서버에게 Node 1 의공용키를요청하여 Node 1 을검증한후일치하는경우연결을허용한다. 이경우 LDAP 서버는단순히키의저장장소의역할뿐만이아니라연결을허용할호스트들의목록을가지고있는파일의역할도동시에수행한다. 이방법을통해서는연결을요청하는클라이언트가실제클라이언트가맞는지즉클라이언트에대한확인은하지만, 사용자를확인하지는않는다. 그러나, 이방법을사용한다고하더라도보안에는문제가없게된다. 왜냐하면, 다른사용자인체하려는사용자는 SSH 와비슷한기능의프로그램을작성해야만하지만다른사용자인체하려는사용자가작성한프로그램은파일시스템에의해보호되고있는호스트에대한사적키를읽어서서버가보내는암호화된숫자를해독할수가없기때문에작성한다고하더라도다른사용자인체하면서로그인하는것은불가능하다. 즉, 다른사용자인척하려는공격은파일시스템에의해보호되고있는호스트의사적키가안전하다는가정하에불가능하게된다. 따라서, 실제적으로는이방법을사용한다고하더라도다른사용자인척한다거나다른호스트인척하는방식의공격은어렵게된다. < 그림 7> 은 LDAP 을사용한가장보안이강화된세번째사용자인증과정을보여준다. - 7 -
L DA P S e r v e r R e q u e s t U s e r P r i v a t e K e y R e q u e s t Us e r P u b l i c K e y No d e 1 No d e 2 No d e 3 No d e 4 < 그림 7> LDAP 서버에서해당사용자의공용키, 사적키를가져오는과정 < 그림 7> 처럼세션키가생성된후 Node 2 는사용자의공용키를 LDAP 서버에게요청하여받은후 Node 2 는임의의수를생성하여암호화하고 Node 1 으로보내고 Node 1 은 LDAP 서버에게사용자의사적키를받아서해독해본후 MD5 해쉬값을보내 Node 2 에게검증을요청한다. Node 2 는이전에생성한숫자와해쉬값이일치하면연결은허용된다. 사용자인증방법중세번째방법인사용자의공용키와사적키를이용하는방법을사용할때는사용자의공용키와사적키를 LDAP 서버에저장함으로써관리의문제를해결할수있다. 공용키의경우는보안의문제가없지만사적키의경우는임의의요청에대해서비스가되는경우보안의문제가발생한다. 그러므로 LDAP 을통해사적키를읽는경우에는적절한권한이있는경우에만허용해야한다. LDAP 을통해사적키를읽으려는경우사용자에게암호를요구하는기능은 LDAP 을통해구현할수있지만, 사적키를요청할때마다암호를입력해야하는문제가따른다. 이문제는프락시 (SSHAGENT) 를두어사용자가암호를한번입력하면사적키를읽어와저장함으로써정해진시간동안에는사용자로부터추가의암호를입력하는수고를더는방법을사용하여해결할수있다. 즉, LDAP 을사용한사용자인증의두번째방법과같이다른사용자인척하려는방식의공격은 LDAP 에서어떤사용자의사적키는오직해당사용자만이읽을수있도록설정해두고이경우사용자의패스프레이스와사용자의암호를입력해야하는문제는 SSHAGENT 라는프로그램을이용하여처음한번만입력하도록하는방식으로해결한다. 4. 구현 LDAP 을통한위에서설계한 SSH 키관리시스템을구현하기위해리눅스기반에서 Redhat Linux Version 2.4.4[12], OpenLdap 1.2[13] 프로그램과 OpenSSH 2.1[14] 를사용하였다. 3 장에서설명한구조를구현하기위해서는크게 LDAP 에서필요한작업과 SSH 에서필요한작업두개로나누어지는데먼저 LDAP 에서는 SSH 키를저장하기위해 LDAP 에적절한스키마를정의하는작업이필요하였고 SSH 의키들을 LDAP 에안전하게입력하기위한툴들을만들었으며베어울프의각노드들이 LDAP 과안전하게통신하기위한암호화작업을하였다. 다음 SSH 측면에서는호스트들을검증하기위해호스트들의키를파일에서읽어본후존재하지않으면 LDAP 에서 SSH 키를추출하기위해서 SSH, SSHD, SSHAGENT 프로그램의수정이요구되었다. - 8 -
< 그림 8> 호스트공유키스키마정의 < 그림 9> 사용자키스키마정의 < 그림 8> 은서버의인증과관련한 LDAP 스키마이고, < 그림 9> 는기존의사용자인증과관련된스키마에추가되는사용자키관련 LDAP 스키마이다. < 그림 8> 이나타내는것은 Host 라는엔트리안에 hostname, hostpublickey 이라는어트리뷰트를각각스트링타입, 이진타입으로정의한내용이며 < 그림 9> 는마이그레이션툴을사용하면자동으로생성되는 account 라는엔트리안에 userprivatekey, userpublickey 라는추가의어트리뷰트를모두이진타입으로정의한내용이다. 위와같이스키마를정의한후스키마에맞게사용자정보와호스트정보를입력해주어야만하는데, 사용자계정을 LDIF 포맷에맞게변경하기위해마이그레이션툴을사용하는데, 이툴을변경하여사용자키도또한위와같이변경한스키마에맞게자동으로 LDAP 에입력할수있었다. 그리고호스트공유키를 LDAP 에저장하도록하는 SSHHKTLDAP 이라는툴을개발하였다. 사용자의사적키를 Base 64 인코딩하여저장한후 LDAPSEARCH 툴을사용하여내용을살펴보면올바로보이지는않지만실제 LDAP 안에는올바르게저장이된다. 또한, LDAP 의설정파일안에접근제어부분의설정에서사용자의사적키부분은, 해당사용자가아닌다른사용자는해당사용자의사적키를읽을수없도록설정해주어서, 어떤사용자가다른사용자의사적키를읽는것을불가능하게해주어야만한다. LDAP 설정에서마지막으로해주어야할일은, LDAP 서버와베어울프내의각노드와의통신에있어스니퍼링을방지하기위해 Secure LDAP 을사용해야만한다. SSH 의동작방법은파일과 LDAP 을동시에사용하도록변경되었는데 SSH 프로그램과 SSHD 프로그램과 SSHAGENT 프로그램이변경되었다. SSH 프로그램에서는처음에서버의인증을위하여호스트의공유키와사용자인증중세번째방법을사용하고자할때 - 9 -
사용자의사적키가필요한경우파일을참조하고, 없으면 LDAP 서비스를이용하도록수정하였고, SSHD 프로그램은사용자인증중두번째방법을사용하고자할때역시파일이존재하지않는경우 LDAP 에요청해서클라이언트의공용키를가져오도록하면된다. SSHAGENT 는사용자인증방법중세번째방법을사용하려고할때 SSH 프로그램대신에인증을해주는역할을해주는데사용자의사적키를파일에서찾아보고없으면 LDAP 서비스를이용하도록수정하였다. 그리고 SSHAGENT 는위의 LDAP 설정에서사용자의사적키는오직해당사용자만이읽을수있도록설정했기때문에 LDAP 에서사용자의사적키를가져오기위해암호를한번입력하고, 사적키를로딩하기위해해당사적키를생성할때입력한패스프레이스를한번입력할필요가있다. 이렇게암호와패스프레이스를입력하여한번만변경된 SSHAGENT 에사용자의사적키를로딩해두면암호를따로입력할필요없이 SSHAGENT 프로그램이실행중인어느노드나 SSH 프로그램을사용하여인증이가능하다. 5. 결론최근에는 IP 만가지고인증을행하는 RSH 의보안의문제때문에보안이강화된 SSH 의사용이많이늘어나고있다. 베어울프와같은환경에서환경내의모든노드들이동일한사용자들을가지며한노드에서작업중이던사용자가다른노드에서 SSH 를사용하여작업을계속하기위해서는빠르고간편하게인증을해야하는작업이필요한데기존의 SSH 에서는이것을위해서는사용자키나호스트키를다른모든노드로복사해주는등의작업이필요했다. 이것은사용자나노드가수시로업데이트되는경우불편하고시간이오래소모되는작업이되는데이러한문제를해결하고자이논문에서는키들의중앙저장장소로써 LDAP 을사용할수있도록 LDAP 에스키마를추가하였다. 또한기존의 SSH 프로그램이인증에필요한각종키들을파일에서읽어오도록되어있기때문에 LDAP 에서읽어오도록 SSH 프로그램을변경하였다. 이렇게 LDAP 을기존의인증과 SSH 키관리를위한중앙인증도구로써사용하면, 기존의각호스트별로분산되어파일로관리되던방식에비해키들의관리비용을줄일수있는장점을갖는다. 베어울프내에노드가추가될때는, 추가된노드의이름과공용키를중앙의 LDAP 서버로추가하고, 추가된노드에계정의관리를 PAM 을통해 LDAP 서버를사용한다고설정하고변경된 SSH 프로그램들을복사만해주면자유롭게 SSH 를통해보안이유지되면서추가의인증을필요로하지않고해당베어울프내의어느노드로나로그인이가능해지게된다. 또한, 사용자가추가될때는, LDAP 을중앙인증도구를사용함으로써간단히 LDAP 서버에한명의사용자를추가함으로써, 베어울프내의모든노드들은추가된사용자를인식하게된다. 이논문에서제안된방법은 LDAP 서버간의신뢰를기반으로클러스터간의상호인증방법으로확장될수있어서그리드 [15] 컴퓨팅환경에도유용하게사용될수있을것으로여겨진다. 6. 참고 [1] The Beowulf Project, http://www.beowulf.org [2] "bwatch" http://nereida.deioc.ull.es/html/ bwatch.html [3] "SCMS" http://smile.cpe.ku.ac.th/research/ scms1.2.2/ [4] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen SSH Protocol Archit ecture http://www.ietf.org/internet-drafts/ draft-ietf-secsh-architecture-13.txt - 10 -
[5] W. Yeong, T. Howes, S. Kille, "Lightweight Directory Access Protocol," RFC 17 77 http://www.ietf.org/rfc/rfc1777.txt [6] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol(v3)", RFC 2251, http://www.ietf.org/rfc/rfc2251.txt [7] Robert T.Morris, "A Weakness in the 4.2 BSD Unix TCP/IP, Software", February 25,1985 [8] Scott Mann,Ellen L.Mitchell, "Linux System Security(The Administrator's Guide to Open Source Security Tools)", pp257-312, Prentice Hall [9] T.Ylonen, "The SSH(Secure Shell) Remote Login Protocol", November 15,1995, http://www.net.lut.ac.uk/psst/rfc [10] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access Protocol(v3): E xtension for Transport Layer Security", RFC 2830, http://www.ietf.org/rfc/rfc2830.tx t [11] Pluggable Authentication Modules(PAM), http://www.kernel.org/pub/linux/libs/pam/pre /doc/current-draft.txt [12] RedHat Linux", http://www.redhat.com [13] "OpenLdap", http://www.openldap.org [14] "OpenSSH", http://www.openssh.com [15] Grid Computing Info Centre(GRID, Infoware)", http://www.gridcomputing.com [16] "IP Spoofing Attacks and Hijacked, Terminal Connections", http://www.cert.org/advisories/ca-1995-01.html - 11 -