요새 서버 B가 있습니다. 개인 키를 사용하여 A에서 B로 C로 SSH해야합니다.

더 나은 옵션은 무엇입니까?

• 개인 SSH 키를 서버 B 에 넣습니다 . 프로덕션 환경 에서는 개인 SSH 키를 사용 하는 것이 좋지 않습니다.

  에서 여기 :

  배스 천 인스턴스에 SSH 개인 키를 두지 마십시오. 대신 SSH 에이전트 전달을 사용하여 먼저 요새와 개인 서브넷의 다른 인스턴스에 연결하십시오. 이를 통해 SSH 개인 키를 컴퓨터에 보관할 수 있습니다.

• SSH 에이전트 전달을 사용하십시오 . 에이전트 전달을 설정하려면 TCP 전달을 허용해야합니다. 에이전트 전달을 설정하면 전달 호스트에 소켓 파일이 작성되는데, 이는 키를 대상으로 전달할 수있는 메커니즘입니다. AWS의 요새 설정에서 :

  TCP 전달 :이 값을 true로 설정하면 TCP 전달 (SSH 터널링)이 활성화됩니다. 이 기능은 매우 유용 할 수 있지만 보안 위험이 있으므로 필요하지 않은 경우 기본 (비활성화) 설정을 유지하는 것이 좋습니다.

  또한 여기에서 :

  유해한 것으로 간주되는 SSH 에이전트 전달

더 나은 게 뭐야? 두 번째 링크의 대안은 어떻습니까? ProxyCommand , 소켓 파일 문제에 도움이 된다는 것을 이해하지만 여전히 TCP 전달을 활성화해야한다고 생각하므로 충분히 안전합니까?

ProxyCommand 또는 ProxyJump 사용

사용하는 것이 좋습니다 ProxyCommand(또는 ProxyJump구문이 더 쉬우지만 클라이언트 측에서 openssh 7.3 이상이 필요하므로 더 좋습니다 ). Bastion에 개인 키를 배포 할 필요가 없으며 모든 것이 로컬에 유지됩니다.

ProxyJump를 사용한 예

클라이언트 컴퓨터에서 다음 ~/.ssh/config과 유사한 내용으로 파일을 작성합니다 .

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

그러면 ssh srvC에이전트 전달없이 B (bastion)를 통해 C에 연결하거나 개인 키를 요새에 배포 할 수 있습니다.

위의 예에서 "bastion"은 Bastion 호스트의 별칭이고 srvC는 서버 C의 별칭 HostName입니다. 호스트의 IP 또는 실제 정규화 된 도메인 이름을 입력해야합니다. 사용자의 User경우 Bastion 및 서버 C에서 올바른 로그인 이름 을 업데이트해야 합니다. 마지막으로 IdentityFile로컬 에이전트 (예 : KeeAgent 또는 ssh-agent)를 사용하는 경우 선택 사항이지만 실행되지 않는 경우에는 선택 사항입니다. 각 주요 암호 문구를 요구하십시오.

공개 키 배포

물론 공개 키를 요새와 srvC 모두 에 배포해야합니다 . 사용할 수 있습니다 ($ 기호는 프롬프트를 나타 내기위한 것이며 입력하지 마십시오).

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

참고 : 위의 비밀번호 인증이 여전히 허용 된 경우에만 작동합니다. 위의 배포 및 모든 것이 의도 한대로 작동하는지 확인한 후 두 서버에서 비밀번호 인증을 허용하지 않아야합니다.

ProxyJump 대신 ProxyCommand를 사용한 예

ProxyJump(클라이언트 측에서) 지원하지 않는 이전 버전의 OpenSSH가있는 경우 다음을 교체하십시오.

ProxyJump bastion

으로

ProxyCommand ssh -q -W %h:%p bastion

내가 이해하는 한 이것은 비슷합니다.

ProxyJump에 대한 답변을 보았습니다. ProxyCommand 에 대해 이야기합시다 .

그러나 기다려라! 에이전트 전달을 사용 하는 서버를 해킹하는 방법을 알려 주면 차이점을 이해하기가 훨씬 쉬워집니다!

해킹하자!

기본 단계 : 여기 내 게시물을 읽을 수 있습니다

기본 단계는 다음과 같습니다.

1. 요새 사용자 만들기
2. 루트 로그인 비활성화
3. 해킹 시도 차단
4. 포트 변경
5. 방화벽 구성
6. SELinux 구성

AgentForwarding 사용 방법

~ / .ssh / config에서 구성 만들기

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

ssh-agent에 인증 키 추가

ssh-add ~/.ssh/name_rsa

요새 호스에 연결

ssh bast

요새에서 응용 프로그램 서버 연결

 ssh app@IP -p PORT

해킹!

당신은 나에게 질문을 할 수 있습니다.

• 내 서버는 안전합니까? 대답은 매우 간단합니다.

  • 아니!

• 왜?

  • SSH 에이전트 전달을 사용하고 있기 때문에!

• 그리고 문제는 어디에 있습니까?

  • 에이전트 전달은 위험하며 유해한 것으로 간주됩니다.

• 왜?

  • 요새 호스트를 연결하면 영광스러운 ssh-agent가 전달됩니다. 이는 누군가가이 소켓 데이터를 사용하여 서버에 액세스 할 수 있도록 소켓이 설정됨을 의미합니다. 요새 서버가 손상되었다고 상상해보십시오. 누군가 Linux 서버에 대한 충분한 권한이 있으면 소켓 정보 만 사용합니다. 결과적으로 모든 서버에 액세스 할 수 있습니다. 요새 호스트에 얼마나 많은 시간이 연결되어 있는지에 따라 타협 창이 매우 작다는 것을 알고 있습니다. 그러나 ProxyCommand와 같은 다른 옵션이있을 때 실제로 위험에 처하고 싶습니까? 따라서 ProxyCommand를 사용하십시오!

요새 호스트가 손상된 경우 서버를 해킹하는 방법은 무엇입니까?

대상 추적

/ tmp 디렉토리에는 다음과 같은 내용이 표시 될 수 있습니다.

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

임시 파일을 열어 봅시다

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

이 프로세스 ID에 대한 연결 을 보자 .

netstat -nxp | grep  10507

결과:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

과 사람을 연결되어 있습니까?

lsof -i -a -p 10507

결과:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

소켓 파일도 볼 수 있습니다 :

cd /proc/10507/fd/
ls

결과:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

그리고 무슨 일이 클라이언트 때 연결됩니다 원격 서버에? 보자 :

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

netstat를 사용하여 소켓 파일이 사용되는지 확인할 수도 있습니다.

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

소켓 정보 및 IP 주소 도용

이제 요새 호스트 세션이 열려있는 동안 소켓 정보를 훔쳐 야합니다 . 또한 대상 서버 IP 도 필요 하므로 netstat를 사용하십시오.

netstat -tn

마지막 단계 사용하는 전달 된 소켓 파일을

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

키가로드되어 있는지 확인하십시오 .

ssh-add -l

결과는 다음 과 같아야합니다 .

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

서버가 해킹당했습니다. 보안 문제를 해결하는 방법은 무엇입니까?

프록시 명령

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

기본 작업 : 서버를 통해 파일을 전송하는 방법 (클라이언트에서 서버로, 서버에서 클라이언트로), 내 게시물을 읽을 수 있습니다.

결론

• 요새 호스트를 사용하는 경우 AgentForwarding을 사용하지 말고 ProxyCommand를 사용하십시오.
• 인증을 위해 항상 루트가 아닌 사용자를 사용하십시오.
• 방화벽을 사용하고 불필요한 모든 연결을 차단하십시오.
• SELinux 사용 (일반)
• 잘못된 자격 증명으로 여러 번 로그인을 시도하는 IP 주소 차단
• 필요하지 않은 경우 사용자에게 sudo 권한을 부여하지 마십시오
• 서버 모니터링
• 보안 패치를 위해 서버 업데이트

자세한 내용은 내 블로그를 참조하십시오 . 또한 나는 약간의 screeenshots를 가지고 있으므로 도움이 될 수 있습니다.

다른 에이전트 와 마찬가지로 SSH 에이전트 전달을 사용하십시오 .

• 키는 랩톱의 ssh 에이전트 에 있습니다.
• 에이전트를 통해 인증 된 요새에 로그인합니다.
• 거기에서 인증 요청이 노트북으로 다시 전달 되어 대상 호스트에 로그인합니다 .

장점 : 오용 할 수있는 요새에 키가 저장되어 있지 않습니다.

희망이 있습니다 :)