By 리차드 실버만(Richard Silverman)
관련기사: SSH 관련 10가지 질문(1부)
6) 한쪽에서는 SSH Communications Security에서 다운받은 SSH2를 사용하고 다른 한 쪽에서는 다른 SSH 소프트웨어를 사용하는데, 1시간만 지나면 연결이 끊어집니다.
버전 2.3.0부터 SSH2는 세션 키 재생성(rekeying)을 구현한다. 이는 SSH-2 전송규약의 특성으로, 전송규약은 세션에 대한 암호와 보전을 변환해서 한 쪽에서 다른 쪽 키를 바꾸도록 해 준다. 이러한 일은 수초마다 혹은 용량이 큰 데이터가 전송될 때마다 주기적으로 일어난다. SSH2 설정 변수인 RekeyIntervalSeconds가 이 특성을 제어하는데, 변수의 디폴트값은 3600이다(클라이언트와 서버 측 둘 다 1시간).
문제는 현재 다른 SSH-2 구현은 세션 키 재생성(rekeying)을 지원하지 않아서, SSH2로부터 키 재생성 메시지를 받을 때 SSH-2는 접속이 끊겨 버린다는 것이다. 키 재생성은 반드시 필요한 과정이므로 SSH2에 있는 키 재생성을 꺼버려야 한다. 그리고 나서 RekeyIntervalSeconds을 0으로 맞춰 놓으면 된다(서버 측 /etc/ssh2/sshd2_config에, 클라이언트 측에는 ~/.ssh2/ssh2_config에서)
실제로 OpenSSH의 상대측과 대화할 때 SSH-2.4.0은 인식 코드가 있어 세션 키 재생성을 나타나지 않게 해서 OpenSSH와 잘 작동하게 해 준다.
7) 스크립트에서 sftp를 어떻게 사용합니까? “here-documents" 셸이 작동하지 않는 것 같습니다.
“here-documents" 셸 스크립트는 다음과 같다:
#!/bin/sh
echo "OK, starting now..."
sftp remotehost < |
실행되지 않는 이유는 sftp가 터미널로부터 명령이 올 것이라 생각하는데, 터미널이 보이지 않기 때문이다. 이제 sftp에는 -b 옵션이 생겼고, 파일로부터 명령을 읽어 들일 수 있다. 하지만 추적을 쉽게 하려면, 용량이 작은 여러 개의 파일에 분산시키는 것보다는 한 곳에 모두 저장하는 것이 좋다. 이것이 here-document이다. 만약 운영체제에 프로세스가 파일시스템을 통해 표준 입력하는 길이 있다면, 다음과 같은 기술을 사용해도 된다: sftp -b /dev/stdin (이것은 리눅스, OpenBSD,용이다; 솔라리스에서 장치 파일은 이렇게 될 것이다: /dev/fd/0)
csh와 유도된 셸로 리눅스에서 이 기술을 사용할 때에는 작은 문제가 발생할 수 있다. 이 문제를 피하기 위해서는 sh나 배시(bash)를 사용하면 된다. 더 자세한 사항을 알고 싶으면 여기에 있는
FAQ를 읽으면 될 것이다.
이와 별도로 사용자를 입력하지 않아도 되는 인증 메소드를 사용할 경우도 있을 것이다. “here-document”를 통해서 sftp의 패스워드를 알려줄 수는 없기 때문이다. 이를 위해 SSH는 터미널에 프롬프트를 띄운다.
Expect를 사용하거나 의사 터미널(pseudo-terminal)에 하위프로세스의 표준 입력을 제공함으로써 이 문제를 해결할 수는 있지만, 굳이 그토록 안전하지 못한 방식으로 할 필요는 없다. 스크립트 내부에 패스워드를 내장하는 것은 좋은 생각이 아니다. 만약 SSH의 위험이 없는 프로세스를 자동화하려 한다면, 이보다 더 나은 방법이 있다. 여기에 있는
FAQ를 보면 패스워드를 입력하지 않고 로그인할 수 있는 방법이 나타나 있다.
8) SSH rc 파일(/etc/sshrc or ~/.ssh/rc)을 사용하기 시작했습니다. 작동은 하지만 이번엔 X 포워딩이 깨졌습니다!
만약 sshd가 rc 파일을 실행시키면, 프록시 표시키를 부가하는 xauth는 구동하지 않는다. 그 대신 표준 입력에 있는 rc 프로그램에 키를 공급한다. 필요하다면 예전처럼 프로그램이 키를 처리하도록 남겨 놓고 말이다. 이를 간단하게 해결할 수 있는 방법은 rc 파일에서 이와 같은 코드를 사용하는 것이다(sshd OpenSSH의 매뉴얼 페이지에 나와 있다):
if read proto cookie;
then echo "add $DISPLAY $proto $cookie" | xauth -q -;
fi
|
9) 부하 공유(load sharing)를 위해 여러 개의 A 레코드가 있는 DNS 이름을 사용해서 호스트에 연결하려고 합니다. shell.isp.com 는 login1, login2, 그리고 login3 호스트에 대한 주소 중 하나는 되돌아옵니다. 계속해서 나타나는 “호스트 키가 바뀌었습니다” 라는 경고를 피하는 방법이 있습니까?
SSH1/OpenSSH에서 알려진 호스트 리스트는 사실상 일련의 키를 각각의 서버 호스트에 연결한다. 이는 사용자가 지정한 호스트 이름과 연결된 키를 가지고 있다는 것을 서버가 입증하기만 하면, 서버 인증이 성공적으로 수행된다는 뜻이다. 결국 알려진 호스트 파일(/etc/ssh_known_hosts or ~/.ssh/known_hosts)에서 실행하면 문제는 생기지 않는다:
login1.isp.com,shell.isp.com 1024 33 1154384130451572942232...
login2.isp.com,shell.isp.com 1024 37 1108041442656325336292...
login3.isp.com,shell.isp.com 1024 33 6656072592185413312026...
|
이는 세 개의 로그인 호스트 키와 shell.isp.com 라는 이름을 연결하는데, 이때 세 개의 키 중 하나를 유효한 호스트 키로 설정해 준다.
주의: SSH2에서 호스트 키를 저장하는 방법으로는 할 수 없다.
10) OpenSSH 서버의 X 포워딩을 사용하고 있습니다. 대부분의 프로그램에서는 작동하지만 linuxconf에서는 작동하지 않습니다!
linuxconf는 하위프로세스를 시작하기 전에 위험한 환경을 제거해 버린다. linuxconf가 /bin/remadmin을 요청하면 XAUTHORITY 변수가 실행되지 않으며, 그 결과 remadmin이 시작시키는 X 기반 전처리가 프록시 xauth 키를 찾지 못한다.
빨리 해결하는 방법은 linuxconf를 시작하기 전에 cp $XAUTHORITY ~/.Xauthority를 실행하는 것이다. 하지만 홈 디렉토리가 실제 서버 호스트에 있지 않다면 이로 인해 사용자의 xauth 키가 네트워크에 cleartext로 전송된다는 사실을 명심해야 한다.
