저는 AWS 클러스터를 관리하고 있으며 현재 끊임없이 변화하는 액세스 목록에 대해 공개 키 또는 LDAP 인증을 처리하는 대신 단일 점프 상자를 통해서만 SSH 액세스를 실행할 계획입니다. 대신 점프 박스의 공개 키는 다른 모든 인스턴스에서 승인되며 어떤 사용자가 다른 인스턴스에 액세스할 수 있는지를 제어합니다. 하지만 일반 사용자에게 개인 키를 노출시키고 싶지 않습니다.
ssh [myserver]나의 초기 해결책은 실행 하고 사용자가 ssh username@aws-jumpbox [myserver]에 연결할 수 있도록 하는 간단한 쉘을 bash에 작성하거나 명령만 받아들이는 대화형 세션을 myserver설정하는 것이었습니다 . ssh그러나 나중에 쉘 스크립트에서는 대화형 세션을 생성할 수 없다는 사실을 기억했습니다.
내가 찾고 있는 것을 달성할 수 있는 쉬운 방법이 있습니까? 나는 완전히 잘못된 길을 가고 있는 걸까?
답변1
그러나 나중에 쉘 스크립트에서는 대화형 세션을 생성할 수 없다는 사실을 기억했습니다.
예, 가능합니다. 하지만 이를 명령(연결을 설정하는 명령) -t에 전달해야 합니다.ssh도착하다호스트가 아닌 호스트로 점프~에서점핑 요스트). 그 이유는 런타임에 명령을 지정하면 ssh기본적으로 대화형 세션에 필요한 tty가 할당되지 않기 때문입니다. -t이 문제를 해결하세요.
몇 가지 가능한 대안:
- .
dialog - 대상 시스템의 이름을 딴 각 대상 시스템의 점프 호스트에 사용자를 만듭니다. 이 접근 방식의 단점: 많은 파일에서 사용자의 SSH 키를 유지해야 합니다. 이를 위해서는 일부 구성 관리 시스템을 사용하는 것이 가장 좋습니다. 예를 들어 puppet은
authorized_keys파일 및 SSH 키 직접 처리를 지원합니다. 이점은 어떤 사용자가 어떤 호스트에 액세스할 수 있는지 더 쉽게 정의할 수 있다는 것입니다.
사용자가 SSH 개인 키를 얻을 수 없도록 하려면 해당 사용자도 점프 호스트를 사용 scp하거나 액세스할 수 없도록 해야 합니다. sftp이것은 그들의 일을 더 어렵게 만들 수 있습니다.
전체적으로 개인적으로 당신이 하려는 일이 좋은 생각인지 잘 모르겠습니다. 점프 호스트는 "ssh 키가 너무 많음" 문제를 해결하지 못하고 단지 이동하고 자체 문제를 많이 발생시킵니다(scp/sftp 없음, 추가한 호스트는 공격자가 좋은 대상을 시도하는 데 문제가 있음). 방문하다모두네트워크의 호스트이므로 보안 관점에서 대화형 세션 및 지정된 명령에 SPOF 문제가 있습니다.
대신 다음을 제안합니다.
- AWS 호스트에서 구성 관리 시스템을 사용하고 시작하기 전에 실행 중인지 확인하십시오
sshd. 이는 여러 가지 이유로 어쨌든 좋은 생각입니다. 나는 대안보다 Muppets를 더 잘 알고 있지만 대안이 있습니다. puppet을 사용하는 경우 다음과 같이 사용자의 SSH 키를 사용하여 파일을 만듭니다.
$user_wouter_sshkey = 'ssh public key data' $user_john_sshkey = 'ssh public key data'등.
리소스에 대한 액세스 권한을 부여하려는 각 사용자 그룹에 대해 정의된 유형을 만듭니다.
define dbassh ($username = $title) { ssh_authorized_key {"wouter_dba_$username": key => $user_wouter_sshkey, type => 'ssh-rsa', user => $username, } ssh_authorized_key {"john_dba_$username": key => $user_john_sshkey, type => 'ssh-rsa', user => $username, } }등.
이제 퍼펫 구성의 다른 곳에서 다음을 수행할 수 있습니다.
user {"postgres": ensure => present, purge_ssh_keys => true, } dbassh {"postgres":}
답변2
답변3
1) 점프 호스트에 SSH 보안을 설정합니다. 고정 IP가 없는 경우 회사의 공용 IP 주소 또는 ISP에서 제공하는 IP 주소 블록만 허용하세요. 그런 다음 집에서 일하는 사용자가 먼저 VPN을 사용하여 내부 네트워크에 연결하도록 할 수 있습니다.
https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5
2) 이 점프 호스트 서버에서만 나오도록 다른 서버에 대한 SSH 로그인을 잠급니다.
https://www.freebsd.org/cgi/man.cgi?query=sshd_config&sektion=5
3) 서버에 기능 계정을 생성하고 기능/관리 계정에서 SSH 키를 푸시합니다. sudoer와 같은 다양한 보안 기능을 사용하여 잠급니다. MyCorporation...mycorpsql, mycorpweb, mycorpdev, mycorpsys.
또한 로컬 보안 그룹을 효과적으로 사용하여 su를 잠글 수도 있습니다.
효과적으로는 그룹에서 사용자를 제거하고 해당 계정을 비활성화하면 됩니다. 이를 위해 루트 디렉터리에 스크립트를 만들 수 있습니다.
사용자 제거/종료
#!/bin/bash
# title : deladminusers.sh
# syntax : deladminusers.sh username
gpasswd -d $1 youradmingrouphere
userdel $1
사용자 비활성화
#!/bin/bash
# title : disableadminusers.sh
# syntax : disableadminusers.sh username
gpasswd -d $1 youradmingrouphere
#makes password incomprehensible
sed -i "s/$1:/$1:!/g" /etc/shadow
사용자 활성화
#!/bin/bash
# title : enableadminusers.sh
# syntax : enableadminusers.sh username
gpasswd --add $1 youradmingrouphere
#makes password comprehensible again.
sed -i "s/$1:!/$1:/g" /etc/shadow
4) 점프 호스트에서 모든 서버로 SSH 키를 푸시합니다. 그런 다음 읽기 및 실행만 가능하도록 기능 계정 프로필에서 ssh 파일을 잠급니다.
fiduser@jumphost ~: ssh-keygen -t rsa
fiduser@jumphost ~: for SERVER in `cat ~/serverlist`
do
ssh-copy-id -i .ssh/rsa_id.pub fiduser@$SERVER
done
5) SU가 허용된 사용자를 기능 ID로 잠그고 점프 호스트가 엄격하게 잠겨 있는지 확인하십시오. 점프 호스트에서 일반 바이너리 액세스를 비활성화합니다. 모든 사용자에게 SU 및 SSH를 허용합니다. 점프 호스트의 루트가 아닌 기능 계정도 허용합니다. 로그인 후 비밀번호 없는 SSH에 대한 요구 사항을 최소화합니다.
점프 호스트의 OS 버전에 익숙하지 않습니다. 사용자를 그룹에 추가하여 기본 사용자 명령을 잠그는 것은 배포판 전체에서 해석하기 어려울 수 있으므로 조사해야 합니다.
강력한 대응책을 사용하십시오. fall2ban을 사용할 수 있을까요?
회사 IP 범위를 차단하지 않도록 구성되었는지 확인하세요. 또한 사무실 내부에 Jump-host를 잠그는 것을 잊지 마십시오.