SSH를 통해 서버에 접속하는 경우 비빌번호 없이 공개키를 이용하여 서버에 접속하는 방법을 정리합니다.


가정 : 로컬컴퓨터(맥) ---> Linux



1. 먼저 로컬컴퓨터에서 private/public key를 생성합니다.

    > ssh-keygen -t rsa

      : Enter file in which to save the key (/Users/Steven/.ssh/id_rsa): steven


    : 그러면 생성한 각각의 private/public key 가 생성됩니다. 

      (위의 경우 steven, steven.pub)



2. 공개키(steven.pub)를 접속하려는 대상 서버/컴퓨터 계정하위 .ssh/의 authorized_keys에 복사해 추가합니다.

    : 그리고 authorized_keys를 700권한을 바꿔줍니다.



3. CentOs의 경우 "/etc/ssh/sshd_config"파일을 열어서 "PubkeyAuthentication yes"로 바꿔줘야합니다.

   그리고 이것을 반영하기 위해 "> service sshd reload"를 실행합니다.



4. 그리고 로컬에 돌아와서 ~ssh/config 파일을 열어서 아래와 같이 관리할 서버를 등록해줍니다.

   ** IdentityFile 파일에는 private key를 지정해줍니다.


    Host centos1

        HostName 192.168.56.102

        User appdev

        Port 22

        IdentityFile /Users/Steven/.ssh/steven



    Host ubuntu1

        HostName 192.168.56.104

        User appdev

        Port 22

        IdentityFile /Users/Steven/.ssh/steven



5. 접속 : 아래와 같이 Host alias이름 만으로 간단히 접속할 수 있습니다.

   > ssh centos1

   > ssh ubuntu1




공개 키 암호화의 작동 방식


1976년 Whitfield Diffe와 Martin Hellman은 공개 키 암호화를 만들었습니다. 공개 키 암호화는 암호화 및 암호 해독 프로세스를 근본적으로 변경하여 커다란 혁신을 가져왔습니다.


Diffe와 Hellman은 하나의 공유 비밀 키가 아닌 두 개의 키를 사용할 것을 제안했습니다. 


하나는 비밀로 유지되는 "개인 키"로서 양쪽에 공유되지 않고 한 쪽만 보유합니다. 

두 번째 키는 "공개 키"로서 비밀이 아니며 널리 공유될 수 있습니다. 


두 키 또는 "키 쌍"이라고 하는 이 키들은 암호화 및 암호화 해독 작업에서 함께 사용됩니다. 키 쌍은 특별한 상호 관계를 가지고 있어서 각 키는 상대 키와 짝을 이루어 결합했을 때만 사용될 수 있습니다. 이 관계는 키를 서로 배타적으로 짝을 이루어 묶습니다. 즉 공개 키와 해당 개인 키가 함께 짝을 이루고 이들은 다른 어떤 키와도 연관되지 않습니다.


이러한 짝 편성이 가능한 것은 공개 키 및 개인 키 알고리즘 간의 특수한 수학적 관계 때문입니다. 키 쌍은 서로 수학적인 연관이 있으므로 키 쌍을 함께 사용하면 대칭 키를 두 번 사용하는 것과 같은 결과를 얻을 수 있습니다. 키들은 함께 사용되어야 합니다. 각 개별 키를 사용하여 자체 작업을 실행 취소할 수 없습니다. 즉 각 개별 키의 작업은 단방향 작업으로서 키를 사용하여 자체 작업을 되돌릴 수 없습니다. 또한 양쪽 키에 사용되는 알고리즘은 한 키를 사용하여 쌍의 반대편 키를 판별할 수 없도록 디자인되어 있습니다. 따라서 공개 키를 통해 개인 키를 판별할 수 없습니다. 그러나 키 쌍이 가능하게 하는 수학으로 인해 키 쌍에는 대칭 키에 없는 한 가지 단점이 발생했습니다. 사용된 알고리즘은 암호화된 정보를 무작위 공격에 알려진 공개 키를 사용할 수 없도록 매우 강력해야 합니다. 공개 키는 그 수학적 특성 및 단방향 특성을 통해 공개적으로 알려져 있다는 점을 보완하여 인코딩된 정보를 쉽게 해독하지 못하도록 합니다.

이 개념을 위의 예제에 적용하는 경우 보낸 사람은 공개 키를 사용하여 plaintext를 ciphertext로 암호화합니다. 그런 다음 받는 사람은 개인 키를 통해 ciphertext를 암호 해독하여 plaintext로 되돌립니다.


키 쌍에서 공개 키와 개인 키 사이의 특별한 관계 때문에 한 사람이 각각의 개인과 다른 키를 사용하지 않고 많은 사람들과 함께 동일한 키 쌍을 사용하는 것이 가능합니다. 개인 키가 비밀 상태로 있는 동안 무제한의 사람들이 공개 키를 제공 받아 안정적으로 사용할 수 있습니다. 하나의 키 쌍을 많은 사람들이 사용할 수 있게 되면서 키 관리 요구 사항이 현저히 줄어들어 암호화 작업이 훨씬 유용해졌기 때문에 암호화의 새로운 지평이 열리게 되었습니다. 각 개인마다 하나의 비밀 키를 만들 필요가 없으며 한 명의 사용자가 하나의 키 쌍을 많은 사람들과 공유할 수 있습니다.


키 쌍에서 개인 키는 한쪽에만 속해 있기 때문에 개인 키가 사용된 것으로 나타난 모든 경우 해당 키의 소유자만이 그것을 사용했다고 결론지을 수 있습니다. 이와 같이 개인 키 사용은 서명의 소유자만 실제로 할 수 있기 때문에 종이 문서에 하는 서명과 유사합니다. 


개인 키를 사용하여 소유자의 현재 상태를 확인하는 것과 마찬가지로 서명을 사용하여 소유자의 현재 상태를 확인합니다.

암호화 및 암호 해독 작업에서 키 쌍이 성공적으로 사용되면 그 쌍의 개인 키는 작업의 한 부분에만 사용되었다고 볼 수 있습니다. 공개 키가 하나의 개인 키에만 묶여 있기 때문에 해당 공개 키를 사용하여 연관된 개인 키를 식별할 수 있습니다. 암호화 및 암호 해독 작업에서 특정 공개 키가 성공적으로 사용되면 해당 개인 키가 작업의 한 부분에만 사용된 것으로 유추됩니다. 키 소유자만 개인 키를 사용할 수 있으므로 이는 키 소유자만 암호화 및 암호 해독 작업의 일부를 수행할 수 있음을 의미합니다.






Posted by Steven J.S Min

댓글을 달아 주세요

라우팅 데이블을 설정할때마도 좀 혼동이 되어 정리해봅니다.


The route table is the place to define where packets originating within a given subnet should go.  The "Destination" is the pattern for where the packet is trying to end up (think final destination), and the "Target" is where the packet should go next, to get it one step closer to the intended destination.  


여기서 혼동되는 이유가 "Destination"이라는 것 때문인것 같은데, 다시생각하고 다시생가하면 "Destination"이 맞는데..... 헷갈릴때는 왜 "Source"라고 하지 않았을까 생각도 하게됩니다.


가령, 다음과 같은 라우팅 테이블을 있을경우 

(다음은 VPC 10.213.0.0./16 영역내에있는 한개의 Private Subnet 을 보여줍니다)




다음과 같이 라우트 테이블을 읽으면 이해가 쉬울것 같습니다.


Route 테이블의 정보는 "XXX(Destination) 로 가려고하는 패킷들은, OOO(Target)으로 보내라"라고 읽으면 된다.



1.  10.213.0.0/16 으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 내부(local)로 브로드캐스팅 하라.

     10.213.0.0/16 은 VPC내의 IP들을 의미하므로 VPC내부에있는것으로 읽으면 됩니다.


2.  (그밖의) 모든 곳으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 NAT( eni-e4b5cc80/i-70b5beac)로 브로드캐스팅 하라.


3.  10.200.0.0/24(다른 VPC의 subnet) 으로 데이터를 보내려고하는(destination : 목적지) 패킷들은 모두 VPC Peering 으로 브로드캐스팅 하라.







Posted by Steven J.S Min

댓글을 달아 주세요

스토리지나 데이터베이스를 백업 및 복구하는 과정에서 설정하게되는 중요 지표(값)이 몇개 등장하는데요 RPO(Recovery Point Object) 와  RTO(Recovery Time Objective) 에 대해서 정리해 봅니다.


이 두가지 지표는 결국 Recovery와 아주 밀접한 과계가 있습니다. 


1. RTO(Recovery Time Objective)


어떠한 특별한 어플리케이션 없이도 얼마나 버틸수 있느냐와 관계가 있습니다(시간). 그래서 종종 허용할 수 있는 최대 허용 다운타임과 연관되어 사용되기도 합니다.


RTO는 실제로 리플리케이션, 테이프/디스크 백업에 사용됩니다. 또한 HA 클러스터 구성이나 혹은 그 이상의 견고한 시스템을 구축하는 것과 동반하여 사용되기도 합니다.


만일 RTO가 0(zero)이라고 한다면 이는 해당 애플리케이션이 완벽하게 이중화되어 있고 데이터가 오프 사이트와 그 밖의 장소에 복제되어 보관되어 있어야 함을 의미합니다. 만일 RTO가 48시간 또는 72시간이라면 테이프 백업으로도 충분할 것입니다.


Maximum length of time a system can be down

Glacier takes 3 to 5 hours to restore objects



2. RPO(Recovery Point Object)


허용할 수 있는 데이터의 손실양과 관계되는 것으로 내가 손실을 경험/허용 할 수 있는 최대의 데이터 양이 얼마인가에 관한 문제입니다.. 

다른 말로 하면, 만일 내가 오후 7시에 백업을 하였고, 이 시스템이 다음날 4시(오전)에 붕괴되었다고 한다면, 내가 백업을 하고 난 이후의 데이터들은 완전히 날아가게 되는 것입니다. 이러한 상황에서 RPO는 바로 전날 백업한 것이 됩니다.


High backup frequency means low RPO

Write/delete event to trigger incremental backup means low RPO



결국, RTO와 RPO는 실제로 리던던시의 종류와 백업 인프라에 영향을 미치고 서로 연관이 있게 된다. RTO가 타이트해 질 수록 RPO도 타이트 해 진다. 물론 비용도 동반 상승하게 되고 인프라 환경에 더 많은 돈이 투자되어야 함을 의미하는 것이다.




Posted by Steven J.S Min

댓글을 달아 주세요

이글은 다음에서 정리한 글입니다.

    http://dogfeet.github.io/articles/2011/a-successful-git-branching-model.html

    http://nvie.com/posts/a-successful-git-branching-model



1. develop 브랜치    

    - 갈라져 나온 브랜치        : master

    - 다시 merge할 브랜치    : master, release


    - 다음에 배포할 것을 개발하는 코드는 origin/develop에 두고 관리

    - 코드가 안정되고 배포할 준비가 되면 곧 master로 merge하고 배포 버전으로 태그를 만든다.

        : 이것은 새 버전을 배포하는 것을 의미한다. 

그래서 master 브랜치에 커밋될 때마다 Git hook 스크립트로 자동으로 빌드하고 말아서 운영 서버로 배포할 수 있다.



 2. feature 브랜치    

    - 갈라져 나온 브랜치        : develop

    - 다시 merge할 브랜치    : develop

    - 브랜치 이름 규칙           : feature-[간단한기능설명]


    - 어떤 기능이 다 완성돼 다음 배포에 넣기로 했다면 develop 브랜치에 merge한다.

    - 다음, 아니면 다다음, 어쨌든 조만간에 배포할 기능을 개발하는 브랜치

    - 기능을 다 완성할 때까지 유지하고 다 완성되면 develop 브랜치로 merge한다.

    - 배포에 확실히 넣을 거라고 판단될 때 merge하고 결과가 실망스러우면 아예 버린다

    - 보통 개발자 저장소에만 있는 브랜치고 origin에는 push하지 않는다.



 3. release 브랜치    

    - 갈라져 나온 브랜치        : develop

    - 다시 merge할 브랜치    : develop, master

    - 브랜치 이름 규칙           : release-v.X.X


    - 배포할 수 있을 정도로 develop 브랜치가 준비돼 제품 배포를 준비하는 브랜치

    - 배포하는 데 필요한 버전 넘버, 빌드 일정 등의 메타데이터를 준비하고 사소한 버그도 잡는다. 

        이런 일을 release 브랜치에서 함으로써 develop 브랜치는 다음에 배포할 때 추가할 기능에 집중할 수 있다

    - master 브랜치에 있는 것을 배포하는 것으로 정의했으므로 먼저 release 브랜치를 master로 merge한다

    - 나중에 이 버전을 찾기 쉽도록 태그를 만들어 지금 master가 가리키는 커밋을 가리키게 한다

    - release 브랜치를 develop 브랜치에 merge하고 다음에 배포할 때 release 브랜치에서 해결한 버그가 적용되도록 한다. 

        (Release하는 도중에 사소한 버그를 수정했을수 있으므로)

    - 배포를 마친경우 release 브랜치는 더는 필요 없다. 삭제한다(Optional)


 4. hotfix 브랜치    

    - 갈라져 나온 브랜치            : master

    - 다시 merge할 브랜치        : develop, master

    - 브랜치 이름 규칙               : hotfix-v.X.X.Y --> v.X.X는 배포된 버전을 사용한다.


    - 미리 계획을 세워두지 않는다는 점만 빼면 hotfix 브랜치도 새로운 배포를 준비하는 것이기 때문에 release 브랜치와 비슷

    - 이미 배포한 운영 버전에 생긴 문제를 해결하기 위해 만든다

    - 운영 버전에 생긴 치명적인 버그는 즉시 해결해야 하기 때문에 문제가 생기면 master 브랜치에 만들어 둔 tag로부터 

hotfix 브랜치를 만든다


    - 버그를 잡았으면 다시 master에 merge하고 다시 develop 브랜치에도 merge해야 한다. 

그래야 다음에 배포할 때도 포함된다. release 브랜치를 마치는 방법과 같다.







Posted by Steven J.S Min

댓글을 달아 주세요