'SFTP'에 해당되는 글 2건

  1. 2009.08.13 SSH 인증키 접속 (ssh-agent 활용법)
  2. 2008.10.16 SSH 터널링을 활용한 MySQL Replication 구축
2009.08.13 18:42

SSH 인증키 접속 (ssh-agent 활용법)

 

client 계정의 아이디와 비밀번호를 입력하지 않고 단지 개인키를 사용하기 위한 패스프레이즈(Passphrase) 비밀번호만을 입력하였다. 혹 어떤 독자는 어 똑같이 비밀번호를 입력하는 데 무엇이 더 나아졌지?하고 생각할 수도 있다. 하지만 엄청난 변화가 일어났다고 할 수 있다.

 

일단 이 패스프레이즈는 자신이 키를 만들 때 비밀번호가 없이 만들면 패스프레이즈 비밀번호 마저도 입력하지 않아도 된다. 또 여러 가지 시스템에 예정을 가지고 있는 사용자는 각 시스템에 비밀번호를 기억하지 않고 똑 같은 패스프레이즈 비밀번호를 한번 입력한 후 로그인을 하면 된다.

 

예를 들어 시스템에 client1이라는 계정을 가지고 있는 사람이라면 계정별로 비밀번호를 기억하지 않고 단지 공개키만 해당 시스템에 등록해주면 모든 처리가 완료되기 때문에 편리함은 극대화되고 보안은 강화되었다고 할 수 있다.

 

 

원래 ssh private_key public_key 인증 및 ssh_agent를 이용하여 서버에 패스워드 인증 없이 접속이 가능하다.

 

[1. Private Key 생성하기]

 

 

 

위와 같이 해서 패스워드를 묻지 않고 접속이 가능하다면, 일단계 성공이다. 그런데, 위의 방법으로 접속이 실패했다면 sshd가 인증키로 인증을 허용하지 않기 때문이다.

 

이럴 경우 sshd_config(보통은 /etc/ssh/sshd_config)에 다음 세 줄이 포함되어 있는지 확인하자.

 

 

이 부분에 주석처리가 되어 있으면 주석을 풀어주고, 없으면 추가해 놓은 후, 서버를 재시작하고, 다시 위의 방법으로 시도를 해본다.

 

 

개인키에 대해서 다른 사람이 읽을 수 있는 권한을 가지고 있으면 OpenSSH는 개인키를 무시한다. 다음은 개인키에 대해서 모든 사람이 읽을 수 있게 해주었다.

 

그런 다음 개인키를 사용하려고 하면 다음과 같이 경고 메시지가 뜨고 정확한 암호를 입력해도 계속 경고 메시지가 뜬다. 따라서 개인키는 자신만이 읽을 수 있는 권한을 가지고 있어야 한다.

 

 

마지막으로 서버의 호스트키가 바뀌면 ssh 클라이언트는 어떤 메시지를 사용자에게 보여주는지 알아보도록 하자.

 

루트 사용자로 로그인해서 /etc/ssh 디렉토리에 있는 각종 키 파일을 backup 디렉토리로 옮겨놓는다.

 

 

 

Sshd 데몬을 재시작하면 다시 호스트키를 생성하면서 데몬이 재시작된다.

 

 

Linuxer 사용자 계정으로 로그인해서 SSH 서버에 접속을 하면 다음과 같이 호스트키가 바뀌었으므로 해킹의 위험이 있다는 것을 알려준다. 따라서 한번 설치한 호스트키를 바꾸는 것은 대단히 위험한 일이다. 실습을 마쳤으면 원래의 키로 다시 복구해주고 데몬을 다시 시작해주기 바란다.

 

 

 

[scp(Secure Copy)를 통한 리모트 복사]

 

Scp는 네트워크를 통해서 한 컴퓨터에서 다른 컴퓨터로 파일을 복사할 때 사용한다. 보통 유닉스의 기본 툴인 rcp와 똑 같은 기능을 제공하지만 rcp와 다르게 ssh처럼 보안 채널의 인증의 단계를 거치기 때문에 훨씬 안전하게 파일을 복사할 수 있다. Scp를 사용하는 구문은 다음과 같다.

 

Syntax

Scp 복사할 파일 복사될 위치

 

여러 컴퓨터에 걸친 복사이기 때문에 단순히 파일이나 디렉토리의 위치만을 지정해서는 안되고 어떤 호스트의 계정에 대한 어떤 파일인지를 분명히 명시해야 한다. 앞에서 공부한 ssh와 똑 같은 채널과 인증 방법을 사용하기 때문에 개인키를 사용하기 위한 패스프레이즈를 입력하는 것이 한번 나온다. 물론 비밀번호 기반 인증 깁버을 사용하는 것도 가능하다.

 

다음은 client 사용자 홈디렉토리에 있는 a.txt 파일을 linuxer 계정을 통해서 복사하는 것을 보여주는 예이다.

 

 

보통 컴퓨터끼리 복사할 때에는 디렉토리 자체를 복사(Recursive Copy)하는 경우가 많다.

 

다음의 예는 client 사용자 홈디렉토리에 있는 sample 디렉토리를 linuxer 계정을 통해서 복사하는 것을 보여주는 예이다. Sample 디렉토리에는 a.txt, b.txt 파일이 있고 하부 디렉토리로 subdir이 있다. 하부 디렉토리까지 모두 복사를 하기 위해서는 r 옵션을 추가해 주면 된다.

 

 

 

[sftp(Secure FTP)]

 

전통적인 ftp 프로그램이 보안이 거의 없기 때문에 이 ftp를 대체하기 위한 클라이언트 툴이 sftp이고 서버 프로그램은 /usr/libexec/openssh/sftp-server이다.

 

다음 예는 sftp를 사용해서 안전한 FTP 통신을 하는 것을 보여주는 예이다.

 

 

 

[SSH 설정 파일]

 

/etc 디렉토리를 살펴보면 두 개의 환경 설정 파일이 존재한다.

 

Ssh_config 파일은 클라이언트 유틸리티인 ssh의 설정 파일이고 sshd_config는 서버 데몬인 sshd의 설정 파일이다.

 

이외에도 많은 설정 파일이 존재해서 OpenSSH를 처음 사용하는 사람은 대단히 혼란스럽다. OpenSSH에서 사용되는 중요한 설정 파일의 목록은 다음과 같다.

 

파일 경로

설명

$HOME/.ssh/known_hosts

시스템 전역적으로 신뢰할 수 있는 호스트의 리스트

$HOME/.ssh/identity,

$HOME/.ssh/id_dsa,

$HOME/.ssh/id_rsa

사용자 인증에 대한 개인키가 저장되어 있는 파일이다. 순서대로 SSH1 RSA, SSH2 DSA, SSH2 RSA 프로토콜을 위한 파일이다. 이 파일은 다른 사람이 읽을 수 있으면 개인키로서 기능을 상실한다.

개인키에는 패스프레이즈(passphrase)를 가지고 키를 보호할 수 있는데 패스프레이즈는 3DES 알고리즘을 사용해 파일의 중요한 부분을 암호화 한다.

$HOME/.ssh/identity.pub,

$HOME/.ssh/id_dsa.pub,

$HOME/.ssh/id_rsa.pub

이 파일은 개인키에 해당하는 공개키이다. 목적은 앞의 개인키와 동일한 목적을 가지고 있다.

$HOME/.ssh/config

/etc/ssh/ssh_config가 모든 사용자에 해당하는 설정이라면 이 파일은 각 사용자에 해당하는 설정을 적어 놓을 수 있다.

$HOME/.ssh/authorized_keys

사용자가 로그인할 때 필요한 RSA 또는 DSA 공개키의 목록이 있는 파일이다.

/etc/ssh/ssh_known_hosts

시스템 전역에 걸친 신뢰할 수 있는 컴퓨터의 리스트를 적어 놓는 파일이다. 한 라인에 하나의 컴퓨터가 등록된다.

/etc/ssh/ssh_config

시스템 전역에 걸친 ssh 클라이언트 도구에 대한 설정이다.

/etc/ssh/ssh_host_key,

/etc/ssh/ssh_host_dsa_key,

/etc/ssh/ssh_host_rsa_key

순서에 따라 SSH1 RSA, SSH2 DSA, SSH2 RSA 프로토콜을 위한 호스트 공개키 파일들이다.

/etc/ssh/sshrc

Ssh로 로그인을 할 때, 사용자의 쉘이 시작이 되기 전에 실행해야할 명령어를 적어두는 곳이다.

$HOME/.ssh/rc

Ssh로 로그인을 할 때, 사용자의 쉘이 시작이 되기 전에 실행해야 할 명령어를 적어두는 곳이다. 단 사용자마다 다른 명령을 실행시킬 때 사용한다.

$HOME/.ssh/environment

추가적인 환경변수를 설정할 수 있다.

 

 

다음은 SSH 서버 데몬에 대한 설정 파일인 /etc/ssh/sshd_config 파일의 예이다. 이 파일은 OpenSSH가 설치되면서 기본적으로 설치된 설정 파일이다.

 

거의 모든 라인이 코멘트로 설정이 되어 있기 때문에 사실 이 파일에서 데몬에 관해 설정하는 것은 없다. 즉 이 파일에 코멘트로 만들어 놓은 옵션은 sshd 데몬의 기본 설정이라는 점에 유의하기 바란다.

 

필자는 이 설정 파일에 약간의 코멘트를 추가함으로써 sshd_config 파일에 대한 설명을 마치도록 하겠다.

 

[/etc/ssh/sshd_config]

 

#           $OpenBSD: sshd_config,v 1.53 2002/05/15 21:02:53 markus Exp $

# 다음은 sshd의 시스템 전역 설정이다. 더 자세한 설명은 sshd 매뉴얼을 보길 바란다.

 

# This is the sshd server system-wide configuration file.  See sshd(8)

# for more information.

 

# sshd 'PATH=/usr/local/bin:/bin:/usr/bin' 경로로 컴파일이 되었다.

# This sshd was compiled with PATH=/usr/local/bin:/bin:/usr/bin

 

# 일반적인 경우라고 기본 옵션을 사용하는 것이 가장 좋다.

# 다음의 각 옵션은 OpenSSH에 설정이 되어 있는 기본 옵션이다. 만약 기본 옵션을

# 바꾸고 싶으면 코멘트를 제거한 후 값을 바꾸면 된다.

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options change a

# default value.

 

# 기본 sshd 포트는 22번으로 /etc/services 파일을 보면 확인 할 수 있다.

Port 22

# 지원하는 프로토콜은 SSH2, SSH1이다.

Protocol 2,1

# 한 대의 컴퓨터가 여러 개의 IP를 가질 때 특정 주소에 대해서만 서비스를 해준다.

#ListenAddress 0.0.0.0

#ListenAddress :0.0.0.0

 

# SSH 버전 2를 위한 호스트키

HostKey /etc/ssh/ssh_host_rsa_key

HostKey /etc/ssh/ssh_host_dsa_key

# SSH 버전 1을 위한 호스트키

Hostkey /etc/ssh/ssh_host_key

 

# 서버키의 수명과 서버키의 길이

# 키의 길이는 기본값은 768이고 최대 1024, 최소 512이다.

# Lifetime and size of ephemeral version 1 server key

#KeyRegenerationInterval 3600

#ServerKeyBits 768

 

# Logging

#obsoletes QuietMode and FascistLogging

#SyslogFacility AUTH

#LogLevel INFO

 

# 인증

# 성공적으로 로그인을 하지 못했을 경우 앞으로 몇초간 로그인을 못하게 할지 설정

# Authentication:

 

LoginGraceTime 600

# 루트 사용자의 로그인 여부

PermitRootLogin yes

# 로그인을 하는 전체 사용자의 파일이나 홈디렉토리의 퍼미션을 체크할지 여부

StrictModes yes

 

# SSH 버전 1을 위한 옵션으로 RSA 인증을 허용할지 여부

RSAAuthentication yes

# 공개키 인증을 허용할지 여부 SSH 버전 2에만 해당

PubkeyAuthentication yes

# 공개키를 설치할 파일의 이름

AuthorizedKeysFile          .ssh/authorized_keys

 

# rhosts 인증은 사용하지 말아야 한다.

# rhosts authentication should not be used

#RhostsAuthentication no

# Don't read the 사용자의 ~/.rhosts ~/.shosts를 읽지 않게 한다.

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# 다음이 제대로 작동하기 위해서는 /etc/ssh/ssh_known_hosts이 존재해야 한다.

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#RhostsRSAAuthentication no

# SSH 버전 2와 유사

# similar for protocol version 2

#HostbasedAuthentication no

# RhostsRSAAuthentication HostbasedAuthentication 인증 방법에 대한

# ~./ssh/known_hosts를 신뢰할 수 없을 때 yes로 바꾼다.

# Change to yes if you don't trust ~/.ssh/known_hosts for

# RhostsRSAAuthentication and HostbasedAuthentication

#IgnoreUserKnownHosts no

 

# 터널링된 단순 문자 비밀번호를 허용하지 않을 때는 no로 바꾼다.

# To disable tunneled clear text passwords, change to no here!

#PasswordAuthentication yes

#PermitEmptyPasswords no

 

# Challenge, Response 인증을 허용할지 여부

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

 

# 커버로스 옵션

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

 

# AFS 토큰이 서버로 전달될지 여부

#AFSTokenPassing no

 

# 커버러스 TGT가 서버로 포워딩될 수 있는지 여부

# Kerberos TGT Passing only works with the AFS kaserver

#KerberosTgtPassing no

 

# PAM을 사용해서 키보드 입력을 통한 인증을 하기 위해서 yes로 설정

# 경고 : 이 설정을 활성화하면 'PasswordAuthentication' 옵션은 무시됨

# Set this to 'yes' to enable PAM keyboard-interactive authentication

# Warning: enabling this may bypass the setting of 'PasswordAuthentication'

#PAMAuthenticationViaKbdInt yes

 

# X11 포워딩 기능을 사용할지의 여부, 이 옵션을 비활성화하더라도 각 사용자는

# 이 옵션을 재정의하여 사용할 수 있음

#X11Forwarding no

# X11 포워딩할 때 처음 사용 가능한 디스플레이 수를 지정

#X11DisplayOffset 10

# sshd X11 포워딩 서버를 루프백 주소와 바인딩할지 여부를 결정

#X11UseLocalhost yes

# 사용자가 로그인할 때 /etc/motd 파일의 내용을 보여줄지 여부

#PrintMotd yes

# 사용자가 최종 로그인한 날짜와 시간을 보여줄지 여부

#PrintLastLog yes

# 다른 쪽에 TCP keepalive 메시지를 보낼지 여부

# 한 쪽 시스템이 다운되었을 경우 세션이 계속 연결되어 있는 것을 막기 위해

#KeepAlive yes

# 상호 대화식 로그인을 위해서 login을 사용할지 여부

#UseLogin no

# 네트워크로부터 들어온 요청을 처리하기 위해서 별도의 권한을 가진 자식 프로세스

# (Child Process)를 만들지 여부

#UsePrivilegeSeparation no

 

# 동시 사용자를 처리하기 위해 인증이 되지 않은 연결의 개수

#MaxStartups 10

# no default banner path

# 접속할 때 보여줄 배너 파일의 경로

#Banner /some/path

# 원격 컴퓨터의 IP 주소와 이름이 일치하는지 확인할지 여부

#VerifyReverseMapping no

 

# 외부 서브 시스템을 설정한다 (, FTP)

# override default of no subsystems

Subsystem         sftp       /usr/libexec/openssh/sftp-server

 

 

다음은 SSH 클라이언트 툴인 ssh의 환경 설정 팡리이다. 전역에 걸친 환경 설정 파일은 /etc/ssh/ssh_config이며 각 개인마다 설정할 내용은 $HOME/.ssh/config 팡리이다.

 

[/etc/ssh/ssh_config]

 

#           $OpenBSD: ssh_config,v 1.12 2002/01/16 17:55:33 stevesk Exp $

 

# 이 파일은 ssh 클라이언트 툴에 대한 시스템 전역 설정이다. 자세한 설명은

$ ssh의 매뉴얼을 보면 알 수 있다. 이 파일은 일반 사용자들에게 기본 설정이며

# 각 사용자는 자신의 설정을 따로 저장을 하거나 ssh 명령어를 실행할 때 옵션으로

# 제공할 수 있다.

# This is the ssh client system-wide configuration file.  See ssh(1)

# for more information.  This file provides defaults for users, and

# the values can be changed in per-user configuration files or on the

# command line.

 

# 환경 설정 데이터는 다음과 같은 순서대로 분석된다.

# 1. 명령어 옵션

# 2. 사용자 개별 설정 파일

# 3. 시스템 전역 설정 파일

# 어떤 설정 옵션이든지 간에 먼저 설정을 한 것이 설정값으로 적용된다.

# 따라서 각 컴퓨터에 한정된 정의가 먼저 나오고 다른 디플트값이 뒤에 나와야 한다.

# Configuration data is parsed as follows:

#  1. command line options

#  2. user-specific file

#  3. system-wide file

# Any configuration value is only changed the first time it is set.

# Thus, host-specific definitions should be at the beginning of the

# configuration file, and defaults at the end.

 

# 사이트 전역에 걸친 다양한 기본 옵션 설정들

# Site-wide defaults for various options

 

# 이 파일의 설정에 영향을 받는 호스트 컴퓨터의 이름 '*' '?'이 사용될 수 있다.

# '*'를 사용하면 설정이 모든 컴퓨터에 영향을 미친다는 의미이다.

   Host *

# 인증 절차를 위해서 리모트에 있는 컴퓨터로 포워딜 될 것인지 여부

   ForwardAgent no

# X11 연결이 자동으로 보안 채널을 통해 리다이렉트 될지 여부

   ForwardX11 no

# 사용할 인증 방법을 정의

   RhostsAuthentication yes

   RhostsRSAAuthentication yes

   RSAAuthentication yes

   PasswordAuthentication yes

# sshd 데몬이 없는 것과 같은 이유로 인해서 연결을 실패했을 때 rsh를 사용할지 여부

   FallBackToRsh no

# rlogin/rsh를 사용할지 여부. SSH 프로토콜을 지원하지 않을 때 사용할 수 있다.

   UseRsh no

# AFS 토큰을 리모트 서버에 전달할지 여부

   BatchMode no

# 호스트 IP 주소를 known_hosts 파일에서 추가적으로 찾는다.

   CheckHostIP yes

# yes - $HOME/.ssh/known_hosts 파일에 호스트를 추가하지 않는다.

# no - $HOME/.ssh/known_hosts 파일에 호스트를 자동으로 추가한다.

# ask - 사용자의 확인을 받은 후 $HOME/.ssh/known_hosts 파일에 호스트를 추가한다.

   StrictHostKeyChecking ask

# 개인키 파일의 위치

   IdentityFile ~/.ssh/identity

   IdentityFile ~/.ssh/id_rsa

   IdentityFile ~/.ssh/id_dsa

# 포트번호, 지원 프로토콜

   Port 22

   Protocol 2,1

# SSH 버전 1을 위한 암호화 알고리즘

   Cipher 3des

# SSH 버전 2를 위한 암호화 알고리즘, 순서대로 운선 순위가 있다.

   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc

# Escape 문자

   EscapeChar ~

 

환경 설정 파일에 대한 기본적인 설명만을 하였다. 더 자세한 옵션에 대해서 알고 싶은 독자는 ssh, sshd man 페이지를 확인해보기 바란다.

 

[SSH Agent Agent Forwarding]

 

지금까지 실습을 통해서 SSH를 사용할 때마다 패스프레이즈(PassPhrase)를 입력해야 하기 때문에 그리 편해지지 않았다는 점에 짜증을 내는 독자도 있을지 모르겠다. OpenSSH에는 사용자가 매번 패스프레이즈를 입력하지 않도록 키입력을 도와주고 또한 사용자의 키를 관리해 주는 키 에이전트가 있다.

 

SSH 에이전트는 개인키를 메모리에 로드하고 있다가 클라이언트의 요청이 있으면 에이전트가 SSH 클라이언트를 대신해서 인증을 처리해준다.

 

다음 그림을 보도록 하자. 클라이언트 컴퓨터에 SSH 에이전트를 실행하고 ssh-add 명령을 사용해서 자신의 개인키를 에이전트에 등록한다.

 

물론 등록할 때 한번의 패스프레이즈(PassPhrase)는 입력해 주어야 한다. 일단 에이전트에 등록해주면 개인키는 메모리에 올라가게 되고 SSH 클라이언트 프로그램은 개별적으로 개인키를 접근할 필요 없이 단지 에이전트에 인증 요청을 하면 된다.

 

SSH 클라이언트가 SSH 서버에 접속을 하고 난 후에 사용자 인증 절차가 되면 SSH 클라이언트는 SSH 에이전트에게 자기를 대신해서 인증을 해달라고 요청한다. 이 요청에 대해서 에이전트는 클라이언트를 대신해서 인증 처리를 자동으로 해주게 된다.

 

 

실제 실습을 통해서 얼마나 SSH 에이전트가 편리한 도구인지 알아보도록 하자.

 

일단 제일 먼저 에이전트를 실행시켜보자. SSH 클라이언트가 에이전트를 찾는 방법은 환경 변수를 통해서 찾는다.

 

SSH 에이전트는 클라이언트 프로그램이 자신을 찾도록 환경 변수에 자신을 찾기 위한 정보를 적어 놓는다. 비유를 하면 칠판에다가 약도를 적어 놓고 다른 사람에게 찾아오라는 것과 같다. 이 환경 변수 정보를 이용해서 다른 클라이언트 프로그램들은 SSH 에이전트와 통신을 하게 된다.

 

에이전트를 실행하는 방법은 두 가지가 있다. 첫 번째는 별도의 쉘로 독립해서 실행을 하는 방법(single shell)이 있고, 두 번째로는 현재 실행 중인 쉘의 하부 쉘(sub shell)로 실행시키는 방법이 있다.

 

다음은 SSH 에이전트를 실행하는 명령인 ssh-agent를 실행한 예이다. 이 명령을 실행하면 환경 변수를 설정하는 명령이 출력된다. 하지만 단지 출력만 된 것뿐이지 환경 변수에 등록된 것은 아니다. 따라서 다음과 같이 실행을 하면 SSH 클라이언트 프로그램은 에이전트를 찾을 수 없게 된다.

 

 

따라서 위의 출력이 실행되도록 만들어 주어야 에이전트를 클라이언트 프로그램이 찾을 수 있을 것이다.

 

그 첫 번째 방법이 바로 별도의 쉘로 독립시켜서 실행하는 eval 명령을 사용하는 것이다. Eval 명령을 사용해서 실행을 하면 에이전트는 백그라운드로 작업을 하고 출력이 되는 각종 명령어도 실행이 된다.

 

하지만 단점은 별도의 쉘에서 실행이 되기 때문에 로그아웃을 해도 SSH 에이전트가 종료되지 않는다는 단점이 있다. 따라서 로그아웃 시에 자동으로 프로세스를 중단시키는 스크립트를 만들기도 한다.

 

 

두 번째 방법은 같은 쉘에 에이전트를 실행하는 방법이다.

 

프로세스는 포그라운드로 작동하게 되고 환경 변수는 자동으로 설정이 된다. 또 같은 쉘에서 작동하기 때문에 사용자가 로그아웃을 하면 자동으로 SSH 에이전트 프로세스가 중단된다.

 

단점은 같은 쉘이 묶여 있기 때문에 SSH 자체의 문제가 아닌 다른 요소에 의해서 프로세스가 중단될 수 있다. 하지만 가장 선호하는 방법이다.

 

 

이제 개인키를 등록해야 한다. 개인키를 등록하기 위한 명령은 ssh-add 명령이다. 명령어에 add라는 단어가 있지만 삭제도 가능한 명령이이다. Ssh-add 명령이 사용할 수 있는 옵션은 다음과 같다.

 

옵션

설명

-l

현재 등록이 되어 있는 개인키의 핑거프린트(fingerprint)를 출력한다.

-L

현재 등록이 되어 있는 개인키의 키 전체 내용을 출력한다.

-d

에이전트로부터 키를 제거한다.

-D

에이전트가 가진 모든 키를 제거한다.

 

자신의 홈디렉토리 밑에 있는 .ssh/id_dsa 파일을 로드시켜보자. 처음 로드할 때 한번은 패스프레이즈를 입력해야 한다.

 

[linuxer@ns linuxer]$ ssh-add $HOME/.ssh/id_dsa

Enter passphrase for /home/linuxer/.shh/id_dsa: *******

Identity added: /home/linuxer/.shh/id_dsa (/home/linuxer/.ssh/id_dsa)

 

-l 옵션을 사용해서 등록이 된 키의 핑거프린트를 확인할 수 있다.

 

[linuxer@ns linuxer]$ ssh-add l

1024 be:ac:6c:7e:bd:f1:89:78:01:45:fc:dc:c7:7d:fe:5f /home/linuxer/.ssh/id_dsa (DSA)

 

이제 SSH Agent의 모든 설정이 끝났다. .ssh를 사용해서 리모트 컴퓨터에 로그인해보면 이제는 패스프레이즈를 입력하라는 메시지는 출력되지 않는다.

 

 

이제 에이전트 포워딩(Agent Forwarding)에 대해서 알아보도록 하자.

 

아래와 같이 세 대의 컴퓨터가 있다고 하자. 철수가 A 컴퓨터에서 ssh를 사용해서 B 컴퓨터에 로그인할 때는 A 컴퓨터에 있는 SSH Agent가 인증 처리를 해주기 때문에 철수는 인증에 대해서 별 생각을 하지 않아도 된다. 하지만 B 컴퓨터에 로그인한 후 다시 C 컴퓨터로 연결을 요청한다고 가정해보자.

 

지금까지 배은대로 라면 C 컴퓨터에 연결을 요청하기 위해서는 철수의 개인키가 B 컴퓨터에 있어서 패스프레이즈를 입력하든지, 또는 B 컴퓨터에 에이전트를 띄워서 인증을 처리하게 할 수 있다.

 

하지만 철수의 개인키가 여기 저기 산재해 있는 것은 바람직하지 않다.

 

이런 경우 사용할 수 있는 좋은 방법이 에이전트 포워딩이라는 방법이다. 키를 관리하는 에이전트는 A 컴퓨터에 있고 B 컴퓨터에서 인증을 요청하게 되면 B 컴퓨터에 있는 프락시 에이전트가 A 컴퓨터에 있는 에이전트에게 인증을 요청하게 된다.

 

 

 

에이전트 포워딩 기능을 사용하기 위해서는 /etc/ssh_config나 자신의 홈디렉토리 밑에 .ssh/config 파일에 에이전트 포워딩 옵션을 설정해 주저야 하고

 

C 컴퓨터에는 철수의 공개키가 설치되어 있어야 한다. 따라서 철수의 공개키는 B 컴퓨터와 C 컴퓨터에 모두 있어야 한다. C 컴퓨터에 공개키를 설치하는 것은 이미 앞에서 언급했으므로 공개키를 설치하는 것은 생략하도록 하겠다.

 

ForwardAgent yes

 

 

실습을 통해서 이해해 보도록 하자. 먼저 에이전트를 구동시켜준다.

 

 

B 컴퓨터에 접속을 한다. 하지만 B 컴퓨터에는 SSH 에이전트를 구동시키지 않았지만 에이전트 프락시를 통해서 마치 에이전트가 구동된 것처럼 현재 키 항목을 얻어 올 수 있다.

 

 

마지막으로 C 컴퓨터에 접속을 한다. 앞에서와 마찬가지로 인증 절차는 거치지 않는다.

 

 

 

 

[NOTE]

 

[포트 포워딩(Port Forwarding)]

 

OpenSSH에는 포트 포워딩이라는 기능이 있다. 하지만 고급 기능에 해당하기 때문에 이 책의 범위를 넘는다. 따라서 간단하게 설명을 하고 자세한 내용을 알고 싶은 독자는 관련 서적을 찾아보길 바란다.

 

포트 포워딩을 사용하면 일반적으로 보안에 취약한 어플리케이션도 SSH라는 터널을 이용해 안전한 통신을 가능하게 할 수 있다.

 

로컬 컴퓨터의 메일 클라이언트는 보통은 리모트 컴퓨터의 110번 포트에 연결해서 메일을 가져오게 된다. 이렇게 연결을 하는 것은 단순 텍스트가 네트워크를 타고 오고가기 때문에 해킹에 대한 위험이 있을 수도 있고 파이어월에서 110번 포트를 사용하는 것을 막아 놓았기 때문에 접속이 불가능할 수도 있다. 관리자는 SSH를 사용해서 통신하는 것은 안전하다고 생각하기 때문에 SSH에 대한 포트는 열어 두었다.

 

이런 경우, 로컬 컴퓨터의 사용자는 리포트 컴퓨터의 110번 포트에 연결하지 않고 자신의 로컬 컴퓨터의 5001번 포트에 연결을 한다. 임의의 로컬 포트 5001에 대기 상태에 있던 SSH 클라이언트는 요청을 받아서 SSH 서버에 데이터를 전송하고 전송을 받은 SSH 서버는 원래의 POP3 메일 서버에 데이터를 전송하게 된다. 이와 같은 SSH의 기능을 포트 포워딩이라고 한다.


출처 : http://blog.naver.com/hgh73


Trackback 1 Comment 0
2008.10.16 14:59

SSH 터널링을 활용한 MySQL Replication 구축

Mysql 서버의 데이터를 미러링 할 목적으로 replication 을 셋팅하던 도중에...
갑자기 생각이 나서 한번 해봤습니다.
딴거는 다 포트가 막혀있거나 또는 SSH 터널링을 이용하는데 replication 을 위해..
mysql 포트를 열어야 하는것과 mysql 권한에 원격 로그인을 허용한다는게 좀 맘에 안들어서... ^^

replication 을 구축하기 위해 최소 2개의 mysql 서버가 필요하겠죠.
master 서버 : insert, update, delete 등이 일어나는서버..
slave 서버 : select 를 주로 하는 서버...
우선 두 서버가 리눅스라는 가정하에 설명하겠습니다.
한쪽이 윈도우거나 두쪽다 윈도우인 경우는 별도의 툴들이 필요하니...
대체적으로 replication 을 사용하시는 분들은 둘다 리눅스를 많이 사용할듯 싶으니...

설치 환경
master : fedora4 mysql.4.1.16
slave : centos5 mysql.5.0.41

SSH 터널링
우선 ssh 터널링을 만들어야 합니다.
ssh 터널링은 slave 서버쪽에 셋팅합니다.

# ssh -CNf -L3307:127.0.0.1:3306 ssh계정@master서버IP
패스워드를 입력하자.
이제 slave 서버와 master 서버간에 터널링이 되었다.

# netstats -an | grep LISTEN
하면 3307 포트가 열려있는것을 확인할수 있다.

잠깐 ssh 터널링을 설명하자면 slave 서버에서 로컬(-L)의 3307번 포트로 접속하면 slave의 ssh를 통해..
master 의 ssh 에 접속하여 127.0.0.1의 3306번 포트로 접속한다는것이다.

주의 : 여기서 127.0.0.1 은 slave의 client ssh로 master 서버의 ssh 서버에 접속한 다음에 IP를
의미하는것이므로 127.0.0.1 은 master 서버 자신을 의미한다.
mysql 계정들의 host 권한을 모두 localhost 로 만들어둔 상태라..
127.0.0.1 이 아닌 master 서버의 도메인으로 셋팅한 경우에 접속이 되질 않았다.
이것때문에 삽질을 좀했다.

-f 는 백그라운드로 돌린다는 말이고..
-C는 압축한다는 의미이다.
-N 은 명령어 실해없이 시작한다는 ...

그럼.. 실제로 접속을 해보자.

/usr/local/mysql/bin/mysql -u root -p -P 3307 -h 127.0.0.1
db 리스트 및 내용을 확인해보면 master 로 접속된걸 확인할수 있을것이다.

Tip
위에서 언급한 ssh 터널링은 재부팅되면 초기화 되므로 재부팅시 자동으로활성화 되도록 만들어보자
/root/sshlogin 이란 화일을 만든다음
===========================================================================================
#!/usr/bin/expect
spawn bash -c "ssh -CNf -L3307:127.0.0.1:3306 ssh계정@master서버IP"
expect -re "Password:"
sleep 0.2
send "master서버의ssh계정패스워드\r"
interact
===========================================================================================
위와 같이 입력해준다.
만약 expect 가 없다면 expect 를 yum install expect 해서 설치하거나..
http://rpmseek.com 또는 http://rpmfind.net 에서 찾아서 설치하시길....

이제 해당화일에 chmod 700 권한을 주고... ==> chmod 700 /root/sshlogin
/etc/rc.local 에
/root/sshlogin <== 이부분을 추가..
그럼 리눅스 시스템이 부팅하면서 해당 화일을 실행하고 ssh 터널링이 열린다.

Replication
이제 replication 이 남았다.
일반적인 replication 과 설정이 다른것은 하나밖에 없을것이다.
Slave Server 에서...

Master Server
my.cnf
===========================================================================================
[mysqld]
log-bin = mysql-bin
server-id   = 1
binlog-do-db = db_name1
#binlog-do-db = db_name2
===========================================================================================

Slave Server
my.cnf
===========================================================================================
[mysqld]
server-id       = 2
master-host     = 127.0.0.1
master-user     = 리플리케이션아이디
master-password = 패스워드
master-port     = 3307
# DB 별
replicate-do-db = db_name1
#replicate-do-db = db_name2
# 테이블 별
# replicate-do-table=db_name.tbl_name
===========================================================================================
이제 mysql 서버를 각각 실행시키면 ssh 터널링을 이용해 replication 이 된다.
이문서는 mysql 설치 초기에 replication 환경을 만들기 위한것이다..
mysql 이 서비스 되는 상태에서 replication을 셋팅하는것은 인터넷에 자료가 많으니...

출처 => http://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=55304

 

sftp를 배제한 ssh 터널링을 이용한 ftp 사용하기

FTP는 암호화되지 않은 형태로 인증과정과 파일이 전송이 이뤄진다.이는 전송되는 중간에
스니핑이 이뤄진다면 고스란히 해커(?)의 손에 ID/PW, 전송 파일이 유출될 수도 있음을 의
미한다. 이글에서는 보다 안전하게 ssh 터널링을 통한 FTP 전송과 vsftpd 설정에 대해 소개
한다.

ssh 터널링 만들기

- FTP 서버에서는 ssh 서버가 동작중이어야 한다. (서버명을 free, ID는 truefeel 이라고 가정)
- client에서는 ssh 클라이언트가 있어야 한다.

연결과정을 그러보면.
로컬의 FTP클라언트 -> ssh 클라이언트 -> 네트워크(암호화 전송) -> ssh 서버 -> FTP 서버

터널링을 만들어보자!

# ssh -P10000 -CNf -L10021:free:21 truefeel@free
-C : 압축해서 전송한다.
-N : 명령어 실행없이 시작한다.
-f : 백그라운드로 실행한다.
-L : 원격서버의 포트를 로컬로 포워딩한다. (즉, 터널링을 만들어줌)
     free서버의 FTP(21번 포트)를 로컬의 10021번 포트로 포워딩한다.
     즉 로컬의 10021번 포트를 통해 free의 FTP서버에 접속할 수 있다. 이 때 원격끼리는 암호화되어 전송된다.
    
만약 원격의 ssh서버가 다른 포트를 사용한다면 -p [포트] 옵셥까지 뒤에 붙여주면 된다.
ps aux 하면 ssh가 백그라운드로 떠있는 것을 확인할 수 있다.

ftp명령으로 로컬의 10021번으로 접속을 하면 원격의 free FTP서버로 접속하게 된다.

$ ftp -p localhost 10021
Connected to localhost (127.0.0.1)
220 Secure FTP 서버
Name (localhost:truefeel): truefeel
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
227 Entering Passive Mode (xxx,xxx,xxx,xxx,80,250)
Security: Bad IP connecting.
ftp>

접속은 정상적으로 이뤄졌는데, 명령어를 입력했더니 'Security: Bad IP connecting.'에러가
발생을 했다. /etc/vsftpd.conf에 다음 한 줄을 추가하면 쉽게 해결할 수 있다.

pasv_promiscuous=YES


Trackback 0 Comment 0