Satellite 호스트에서 SSH 활성화하기
문제 해결 및 디버깅 과정에서, Satellite 호스트를 제어 플레인이나 클러스터에 할당하기 전이나 후에 해당 호스트에 대한 SSH 액세스가 필요합니다.
예를 들어, 호스트 할당에 문제가 있는 경우, 클러스터에 할당하기 전에 루트가 아닌 사용자에게 호스트에 대한 SSH 액세스를 허용할 수 있습니다.
호스트에 대한 SSH 액세스를 활성화하는 단계는 다음 섹션을 검토하십시오.
할당 전 RHCOS 호스트에서 루트가 아닌 SSH 활성화
RHCOS
CoreOS 호스트에서는 일반적으로 루트 SSH 액세스가 비활성화되어 있고, root 및 core 호스트 할당 과정에서 SSH 액세스가 비활성화되기 때문에, 기본 core 사용자가 아닌 새로운 비루트 사용자를 추가하여 SSH 액세스를 부여할 수 있습니다.
이 지침은 클러스터나 컨트롤 플레인에 할당하기 전에 Red Hat CoreOS 호스트의 새로운 사용자에게 SSH 액세스를 활성화하는 방법을 설명합니다.
문제 해결을 마친 후에는 이 단계를 되돌리고 SSH 액세스를 비활성화하십시오.
-
CoreOS 호스트를 만들 때 사용한 ignition 파일을 호스트에 첨부하여 새로운
satellite사용자를 만듭니다. Ignition 파일의passwd섹션을 다음과 같이 편집하십시오."passwd": { "users": [ { "name": "core", "sshAuthorizedKeys": [ "" ] }, { "name": "satellite", "sshAuthorizedKeys": [ "ssh-rsa AAA... KEYNAME" ], "groups": [ "sudo" ] } ] }, -
SSH 공개 키를 추가합니다. SSH 키 쌍을 만들려면
ssh-keygen명령을 실행하면 됩니다.ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P '' -
sat-host-access.pub파일에 점화 파일에 추가할 키가 있습니다. 위의 예에서ssh-rsa AAA... KEYNAME를 바꾸어 파일 전체 내용을 점화 스크립트에 추가하십시오.sat-host-access의 개인 키는 호스트에 SSH 접속할 때 사용하는 키입니다.이 호스트에 방금 추가한 공개 키에 해당하는 개인 키와 노드에 대한 네트워크 액세스 권한이 있는 사람은 누구나 이 시스템에 SSH로 로그인할 수 있습니다.
-
선택 사항입니다: 다음
journalctl명령을 실행하여 디버깅용 로그를 수집합니다.journalctl -u ibm-host-attach --no-pagerjournalctl -u ibm-host-agent --no-pagerjournalctl -u ibm-firstboot-ignition --no-pager
RHEL 호스트에서 할당하기 전에 루트가 아닌 SSH 활성화
RHEL
이 지침에서는 RHEL 클러스터 워커 노드에 대한 비루트 SSH 액세스를 일시적으로 사용하도록 설정하는 방법을 설명합니다.
문제 해결을 마친 후에는 이 단계를 되돌리고 SSH 액세스를 비활성화하십시오.
시작하기 전에 할당되지 않은 호스트에 대한 루트 SSH 액세스 권한이 있는지 확인하십시오.
- 이 호스트의 루트 사용자와 동일한 SSH 키를 이 새로운 사용자에게 사용하려는 경우, 다른 키가 필요하지 않습니다. 그러나 이 새로운 사용자에게 다른 SSH 키 쌍을 사용하려면 해당 키 쌍을 준비하거나, 호스트에 SSH를 사용하는 시스템에서 새로운 SSH 공개/비공개 키 쌍을 생성해야 합니다. 개인 키를 누구에게도 제공하지 마십시오. 이 지침은 새로운 키 쌍을 생성했다고 가정합니다.
ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P ''`
호스트 자체에서 나머지 단계를 실행하므로 계속하기 전에 루트 권한으로 호스트에 SSH로 접속하십시오.
-
사용자를 생성하고 암호 없이 전체 sudo 액세스 권한을 갖도록 구성합니다.
useradd -U -m -s /bin/bash satellite && mkdir -p /home/satellite/.ssh && chown -R satellite:satellite /home/satellite/ -
새 사용자에게 SSH 키를 추가하세요.
- 이 사용자와 루트 사용자에게 동일한 SSH 키를 사용하려면 다음 명령을 실행하십시오.
cp -r /root/.ssh/authorized_keys /home/satellite/.ssh/ ``` * 새로운 키 쌍을 만들었거나 기존 공개 SSH 키가 있는 경우, 다음 명령을 실행하여 `satellite` 사용자에게 추가하십시오. ```sh {: pre} echo "<CONTENTS OF ~/.ssh/sat-host-access.pub OR YOUR OWN PUBLIC KEY>" >> /home/satellite/.ssh/authorized_keys && chmod 600 /home/satellite/.ssh/authorized_keys ``` -
다음 명령을 실행하십시오.
chown -R satellite:satellite /home/satellite/.ssh/authorized_keys -
이 새로운
satellite사용자에게 비밀번호 없이 전체 sudo 액세스 권한을 부여하려면 다음 명령을 실행하십시오.echo "satellite ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers사용자의 권한을 더 제한적으로 설정할 수도 있습니다. 이 경우에는 호스트에서 설정하세요. 문제 해결을 위해 이 사용자에게 전체 sudo 액세스 권한을 부여하는 것이 좋습니다. 문제 해결을 마치면 사용자를 제거하거나 권한을 제한할 수 있습니다.
이제 이 호스트와 노드에 대한 네트워크 액세스 권한에 방금 추가한 공개 키에 해당하는 개인 키를 가진 사람은 누구나 루트 권한으로 이 시스템에 SSH 접속할 수 있습니다.
-
노드에 로그인하여 새로운 사용자로 작동하는지 확인하십시오.
ssh -i ~/.ssh/sat-host-access satellite@NODE-IP -
그런 다음 다음 명령을 실행하여 이 사용자로부터 루트 권한을 얻을 수 있는지 확인합니다.
sudo su - root -
선택 사항: 호스트 등록 및 호스트 부트스트래핑 프로세스에서 생성된 다양한 로그 출력 파일을 확인하십시오.
<filepath>을 다음 파일들로 순서대로 교체하여 체크인하십시오. 문제의 성격에 따라, 해당 프로세스가 실행되지 않은 경우 호스트에 일부 로그 파일이 존재하지 않을 수 있습니다.- 호스트 등록 시도에서 생성된
nohup.out로그. - 첫 번째 부트스트랩 시도에 대한
/var/log/firstboot.log. 호스트 등록이 실패한 경우에는 이 파일이 없습니다. - 기본 부트스트랩 프로세스에 대한
/tmp/bootstrap/bootstrap_base.log(첫 번째 부팅이 실패한 경우). 호스트 등록이 실패한 경우에는 이 파일이 없습니다.
tail <filepath> ``` 1. `journalctl` 명령을 실행하여 디버깅용 로그를 수집합니다. ```sh {: pre} journalctl -u ibm-host-agent --no-pager ``` ```sh {: pre} journalctl -u ibm-firstboot --no-pager ``` ```sh {: pre} journalctl -u ibm-host-attach --no-pager ``` - 호스트 등록 시도에서 생성된
할당 후 호스트에서 루트 SSH 활성화
RHCOS RHEL
일부 문제 해결 상황에서는, 클러스터 내에서 이미 워커 노드로 지정된 호스트에 직접 SSH로 접속해야 할 때가 있습니다. 예를 들어, 클러스터 워커 노드가 클러스터 마스터와의 연결을 잃은 경우 등이 있습니다. 이 지침에서는 Satellite 클러스터 내의 Red Hat CoreOS 또는 RHEL 클러스터 워커 노드에 대한 루트 SSH 액세스를 일시적으로 활성화하는 방법을 설명합니다.
문제 해결을 마친 후에는 이 단계를 되돌리고 SSH 액세스를 비활성화하십시오.
시작하기 전에 다음 사항이 준비되어 있는지 확인하십시오.
- SSH 클라이언트 시스템으로 사용할 수 있도록 클러스터 작업자에게 직접 액세스할 수 있는 시스템에 액세스합니다.
oc debug node/NODE-NAME를 실행할 수 있도록 이 클러스터에 대한 관리자 액세스 권한이 필요합니다.
-
SSH 클라이언트에서 SSH 공개/비공개 키 쌍을 만듭니다. 개인 키를 누구에게도 알려주지 마십시오.
ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P '' -
공개 키가 생성되었는지 확인합니다.
cat ~/.ssh/sat-host-access.pub -
클러스터 마스터에 액세스할 수 있고 관리자
kubeconfig액세스 권한이 있는 시스템에서 다음 명령을 실행합니다.oc debug node/NODE-NAME -
NODE-NAME의 쉘에서 다음 명령을 실행하여 루트 SSH를 활성화하십시오.chroot /hostecho "<CONTENTS OF ~/.ssh/sat-host-access.pub>" >> /root/.ssh/authorized_keyschmod 600 /root/.ssh/authorized_keys -
SSHD_CONFIG_FILE의 환경 변수를 설정하려면 다음 명령 중 하나를 사용하십시오. 구성 파일의 위치는 워커 버전에 따라 다릅니다. 두 예시 경로 중 어느 것도 호스트와 일치하지 않는 경우, 계속 진행하기 전에SSHD_CONFIG_FILE환경 변수를sshd설정 파일의 전체 경로로 설정하십시오.CoreOS 의 명령 예시.
export SSHD_CONFIG_FILE="/etc/ssh/sshd_config.d/40-rhcos-defaults.conf"RHEL 9 작업자를 위한 명령 예제입니다.
export SSHD_CONFIG_FILE="/etc/ssh/sshd_config" -
PermitRootLogin설정을 확인하십시오.grep ^PermitRootLogin $SSHD_CONFIG_FILE -
PermitRootLogin을(를)yes(으)로 설정하십시오.sed -i "s/PermitRootLogin no/PermitRootLogin yes/g" $SSHD_CONFIG_FILE -
설정을 확인하십시오.
grep ^PermitRootLogin $SSHD_CONFIG_FILE -
다음 명령어를 실행하여 서비스를 다시 시작한 후 종료하십시오.
systemctl restart sshdexit && exit
이 시점에서, 앞서 생성한 개인 키를 사용하여 SSH 클라이언트 시스템에서 루트 SSH 액세스를 활성화합니다. 이 개인 키를 가진 사람과 노드에 접근할 수 있는 사람은 누구나 루트로 이 시스템에 SSH 접속할 수 있다는 점에 유의하시기 바랍니다. 다음 명령을 사용하여 노드에 SSH로 접속하십시오: ssh -i ~/.ssh/sat-host-access root@NODE-IP.