반응형
SSH authorized_keys 파일 설정
목표
openstack에 centos cloud image 설치해서 instance를 하나 생성하고
해당 instance에 ssh로 접속 시도 했는데 문제가 발생하고 있음.
문제 상황
ssh client에서 아래와 같이 ssh-copy-id 명령으로 public key를 ssh-server로 전송함.
그때 아래와 같은 메세지가 나옴
[명령어]
ssh-copy-id -i id_rsa.pub 10.0.2.11
[결과]
root로 접속 시도 했지만 centos 계정으로 접속하라 권장하는 메세지가 나온 후 key는 전달됨.
이후 root 계정으로 ssh 접속 시도 시 아래와 같은 결과가 나오며
접속이 차단됨.
원인을 파악하기 위해
ssh server의 authorized_keys 파일을 확인해보니 다음과 같은 옵션이 추가되어있음.
no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="echo 'Please login as the user \"centos\" rather than user \"root\".';echo;sleep 10" ssh-rsa AAAAB3~~~
해당 옵션이 어떤 역할을 하는지 파악해보기로 함.
SSH authorized_keys 파일이란?
SSH의 authorized_keys 파일은 SSH 가장 중요한 파일임.
authorized_keys 파일은 public key 인증을 사용하여
원격 호스트에 로그인 하도록 허용된 사용자를 인증하는 데 사용되는 키를 저장하고 있음.
authorized_keys 파일에 public key가 저장되어 있으면
해당 public key를 사용해서 ssh server에 영구적으로 접속할 수 있어서
신경써서 관리가 필요함.
ssh-copy-id를 사용하면 원격 ssh server에
authorized_keys 파일이 없다면 생성해주고 있다면 public key를 추가해줌.
SSH authorized_keys 특징
authorized_keys 파일 경로
default path 경로는 각 계정의 ~/.ssh/authorized_keys 에 있음.
만약 인증서를 통한 접속 시도가 없었다면 authorized_keys 파일은 존재하지 않음.
public key 정보
authorized_keys 파일의 각 line에는 하나의 public key 정보가 포함됨.
SSH 프로토콜 버전 2의 경우 public key 유형은 ''ssh-dss'' 또는 ''ssh-rsa'' 2가지가 있음.
public key 정보는 base64 encoding 되어서 저장됨.
authorized_keys 주석 처리
빈 줄과 '#'으로 시작하는 줄은 주석으로 무시됨.
SSH authorized_keys 옵션
일반적으로 ssh-copy-id 명령을 사용해서 원격 ssh server에 public key를 전달하면
아래와 같은 상태로 public key가 저장되어있고 해당 key로 ssh에 접속할 수 있음.
ssh-rsa 뒤에 public key 값이 있는 것을 확인 할 수 있음.
하지만 특정 ssh server는 다음과 같이
~/.ssh/authorized_keys 파일에 옵션이 추가되어 있음.
이러한 옵션들은 같은 line에 있는 public key에 대해만 적용됨.
해당 옵션에 대해 알아보도록 함.
주의
쉼표로 옵션을 구분함.
큰따옴표 안을 제외하고 공백은 허용되지 않음.
옵션 키워드는 대소문자를 구분하지 않음.
command="command"
해당 public key가 인증에 사용될 때마다 지정한 명령이 실행되도록 함.
주의 사항으로는 ssh server에서 지원하는 명령만 가능함.
[옵션 사용 예제]
command="mkdir /sshTestdir"
[결과]
ssh 연결은 성립되지 않고
즉 ssh server에 지정한 명령이 실행 됨.
ssh server에서 mkdir /sshTestdir 명령이 실행되서
ssh server를 확인해보면 아래와 같이 실제로 /sshTestdir 가 생성되어 있음.
command="echo"
위에서 알아본 바와 같이 command 옵션을 사용하면 connection이 닫힘.
이에 대한 이유를 알아봄.
[옵션 사용 예제]
command="echo test echo!!"
옵션을 추가하고 ssh 연결을 시도하면 아래와 같이 연결이 된 후
echo 문을 실행하고 connection이 종료됨.
[결과]
[원인]
일반적으로 ssh 연결을 하면 새로운 shell이 시작된다고 보면 됨.
즉 일반적으로 ssh 연결 시 연결->인증->shell 실행
단계로 실행된다고 보면 되는데
command echo 명령을 하게되면
연결->인증->echo 명령 실행 및 종료.
단계로 실행되서 shell이 종료됨.
위와 같이 test echo!!가 출력되는건 ssh client가 echo문을 실행하는게 아니라
ssh server에서 해당 echo문을 실행하고 connection을 닫음.
[해결책1]
이를 방지하기 위해
ssh 연결 시 echo문을 출력하고 connection이 유지될 수 있도록 하는 방법은
~/.ssh/authorized_keys 파일에 command 옵션을 제거하고
아래 같이 ssh server의 ~/.bashrc 파일에 해당 스크립트를 추가하면 됨.
$SSH_CONNECTION 환경 변수로
해당 쉘이 ssh를 통해 실행된 것임을 확인 할 수 있음.
|
if [[ -n $SSH_CONNECTION ]] ; then
echo "mail USER : ${USER}, HOSTNAME : ${HOSTNAME} "
fi
|
[해결책2]
command 옵션에 echo 사용 시 끝에 bash 와 같이 사용하고자 하는 shell을 지정해주면 됨.
command="echo test echo!! ;bash"
이와 같이 사용하면 command echo 이후 정상적으로 ssh 연결됨.
environment="NAME=value"
해당 public key를 인증에 사용해서 로그인할 때 환경변수를 추가해줌.
만약 지정한 환경변수가 기존에 있는 환경변수라면 새로 재정의 됨.(덮어쓰기)
[주의]
environment은 보안상 default로 비활성화 되어있음.
해당 옵션을 사용하기 위해서는 ssh server에서 ssh 설정이 필요함
vi /etc/ssh/sshd_config
이동 후
PermitUserEnvironment 옵션을 yes로 설정해주고
ssh 를 restart 해줘야함.
[옵션 사용 예제]
environment="SSHTESTENV=test"
[결과]
authorized_keys 파일에서 설정했던 환경변수가 저장되어있는 것을 확인할 수 있음.
from="pattern-list"
from 설정이 적용된 public key를 인증에 사용하면 로그인 가능한 ip나 host name을 지정할 수 있음.
'*'와같은 옵션 사용 가능하고 쉼표로 여러대의 host 지정가능
예제로
ssh client ip : 10.0.2.15
ssh server ip : 10.0.2.11
인 경우
ssh server의 authorized_keys 파일에 from 설정을 10.0.2.15로 하면
10.0.2.15 ip인 host만 ssh server에 접속할 수 있음.
[옵션 사용 예제]
from="10.0.2.15"
[결과]
ssh server에 정상적으로 접속 가능함.
[옵션 사용 예제]
from="10.0.2.14"
[결과]
ssh client ip가 10.0.2.15라 인증서를 통해 접속이 안되서
password를 물어보는 것을 확인할 수 있음.
no-agent-forwarding
해당 public key를 인증에 사용될 때 agent forwarding 설정을 금지함.
OpenSSH 서버는 no-agent-forwarding 옵션을 지정하지 않는 한
agent forwarding이 default로 항상 활성화되어 있음.
[agent forwarding이란?]
만약 Host1, 2, 3가 있는 경우
(Host 1에서 2로 접속하고 2에서 3으로 접속해야하는 상황이라면)
Host 1이 Host 2에 접속하기 위해 Host 1의 public key를 Host2에 배포해야하고
Host 2가 Host 3에 접속하기 위해 Host 2의 public key를 Host3에 배포해야함.
즉 Host 3는 2개의 public key를 관리해야하고
Host 1, 2는 각각의 개인키를 잘 관리해야함.
이런 경우 보안적으로 key관리가 매우 복잡해짐.
이런 ssh key관리를 단순화 하기 위해서 Host 1의 key pair하나로
모든 server에 접속 할 수 있는 환경을 구성할 수 있음.
(Host 1에서 2로 접속하고 2에서 3으로 접속해야하는 상황이라면)
Host 1의 private key로 Host 2에 접속하고
Host 2에서 Host3에 접속할 때 Host2의 private key가 아닌 Host1의 Private key로 접속함.
설명이 어려운 것 같아서 다시 하자면...
Host 1에서 ssh 로 Host2에 접속함. (Host 1의 private key 사용)
Host 2에서 ssh 로 Host3에 접속함.(일반적이라면 Host2의 private key로 접속해야하지만 Host 1의 private key로 접속)
이것이 바로 Agent forwarding임
즉 SSH Agent forwarding 은
Host1 의 ssh key(private)를 통해서 Host2 뒤의 Host3에 접속하게 하는 방법.
이와 같은 ssh접속 환경을 구성하면 여러대의 host에 private key를 보관하지 않고
특정 host에만 private key를 보관하면 모두 접속이 가능하기 때문에
private key를 보관하고 있는 한대의 host만 보안관리를 잘하면 되서 보안적으로 안전함.
하지만 이 private key를 보관하고 있는 host가 털리면.. 상상하기 싫음..
[예제 ssh agent forwarding 구성]
Host 1 : 10.0.2.15
Host 2 : 10.0.2.11 (Host 1의 public key만 보관 중)
Host 3 : 10.0.2.10 (Host 1의 public key만 보관 중)
Host3는 Host2의 public key를 보관하고 있지 않음
Host 1에서 아래의 명령어 실행 (ssh agent 설정임)
exec ssh-agent /bin/bash
ssh-add ~/.ssh/id_rsa
private key가 agent에 정상적으로 등록 되어있는지 확인하기 위해
ssh-add -L 명령으로 확인
해당 설정이 되어있으면 Host1 - Host2 - Host3 접속이 가능
[agent forwarding 명령어]
ssh -A [주소]
[결과]
Host 1에서 Host2로 Host 1의 public key를 사용해서 연결 성공하고
Host 2에서 Host3로 Host 1의 public key를 사용해서 연결 성공함.
모든 연결에서 Password를 묻지 않음으로 Host 1의 public key를 사용해서 연결 성공했다고 판단할 수 있음
[Host2에 no-agent-forwarding 옵션 사용]
no-agent-forwarding
이런 환경에서 Host 2에 no-agent-forwarding 옵션을 사용하게 되면
agent forwarding 기능을 정지해서
Host 2에서 Host3로 연결 시 Host 1의 public key를 사용하지 못함.
[결과]
Host 1에서 Host2로 Host 1의 public key를 사용해서 연결 성공했지만
Host 2에서 Host3로 연결 시도 시 Host 1의 public key를 사용 못해서 Password를 물어보는 것을 확인할 수 있음.
no-port-forwarding
해당 public key를 인증에 사용될 때 TCP forwarding을 금지함.
클라이언트의 모든 포트 전달 요청은 오류를 반환함.
단 command option은 사용할 수 있음.
[SSH port forwarding이란?]
SSH는 기본적인 접속 기능 외에도 'SSH 포트 포워딩', 'SSH 터널링 기능' 을 제공함. (두 용어는 같은 것을 의미)
자세한 설명 참고
[옵션 사용 예제]
no-port-forwarding
no-pty
tty 할당을 방지하고 pty 할당 요청은 실패하도록 함.
[tty란?]
Tele Type Writer의 약자로 콘솔 및 터미널 환경을 말함.
[pty란?]
Pseudo-Terminal의 약자로 가상 터미널 환경을 말함.
[옵션 사용 예제]
no-pty
[결과]
연결은 성공하지만 command가 생성되지 않아서 명령어 입력 불가능.
no-user-rc
~/.ssh/rc의 실행을 비활성화함.
[~/.ssh/rc란?]
SSH rc 파일은 shell 시작 파일(예: ~/.profile 또는 ~/.cshrc )과 비슷하지만
SSH에서 계정에 액세스할 때만 적용되는 파일임.
/etc/ssh/sshd_config파일에
"PermitUserRC" 옵션이 "no"로 설정된 경우 .ssh/rc가 호출되지 않음.
"PermitUserRC" 옵션은 default로 yes 설정으로 되어있음
"PermitUserRC" 옵션이 없는 경우 yes와 동일함.
예제로 ssh server에 다음과 같은 rc 파일을 생생해보겠음.
이후 해당 ssh server에 ssh client가 연결하면 다음과 같이
rc 내용대로 test_ssh_rc_file이 생성됨.
[옵션 사용 예제]
no-user-rc
[결과]
해당 옵션을 사용하면 ssh server의 ~/.ssh/rc 파일이 실행되지 않아서
test_ssh_rc_file이 생성되지 않음.
no-X11-forwarding
해당 설정이 적용된 public key를 인증에 사용하면 X11 전달을 금지함.
클라이언트의 모든 X11 전달 요청은 오류를 리턴함.
[X11이란?]
X11은 거의 모든 Linux 배포판에서 사용되는 그래픽 서버임.
/etc/ssh/sshd_config 파일에서
X11Forwarding 설정을 yes로 하면 사용가능
default로 yes로 설정되어 있음.
[X11 test]
테스트를 위해 ssh server에 xclock을 설치함
yum install -y xclock
이후 ssh client에서 ssh server에 원격으로 붙은 후
xclock 명령을 하면 시계 그래픽이 추가되는 것을 확인 할 수 있음.
x11 그래픽을 사용하기 위해서는 ssh -X 옵션이 추가되어 있어야함
[옵션 사용 예제]
no-X11-forwarding
[결과]
기존에는 xclock 그래픽이 정상적으로 출력됐는데
no-X11-forwarding 옵션 설정 이후에는
X11 forwarding request failed on channel 0
메세지가 나오고 시계 그래픽이 출력되지 않음
permitopen="host:port"
SSH는 "ssh -L"와 같은 L 옵션이 있음
해당 설정이 적용된 public key를 인증에 사용하면
TCP port forwarding이 허용되는 대상을 지정할 수 있음.
즉 ''ssh -L'' 옵션에 올 수 있는 항목을 정할 수 있음.
permitopen 옵션은 여러 개 올 수 있으며 쉼표로 구분됨.
주소는 IP, 도메인명이 올 수 있음.
ex) permitopen="192.0.2.1:80",permitopen="192.0.2.2:25"
참고
ssh agent forwarding
반응형
'Tool 사용법 > SSH' 카테고리의 다른 글
| HashiCorp Vault Container로 실행 (0) | 2022.04.07 |
|---|---|
| HashiCorp Vault를 이용한 SSH 공개키 인증 (0) | 2022.02.05 |
| AWS EC2 SSH (0) | 2022.01.27 |
| SSH란? (0) | 2022.01.27 |