자동화할 수 있어서 멋짐. 수동 방식으로는 클라우드 제공자 콘솔에서 서버의 SSH 지문을 별도 채널로 확인해 왔음
관리하는 클라우드 인스턴스가 많지 않아서, 프로비저닝에 수동 단계가 몇 개 있어도 괜찮음
그 방식도 동작함. 다만 사용하던 제공자가 그 부분을 연결해 두지 않았고, 동시에 설정 자동화 스크립트를 만들고 있던 상황이었음
DNS 영역을 자동화해 뒀다면 다른 접근도 가능함: 범위가 매우 좁은 일회용 토큰을 만들고, 예를 들어 my-server-hostname.example.net에 레코드 하나 생성만 허용하게 함
그 토큰을 cloud-init으로 서버에 전달하고, 서버가 공개 SSH 키를 DNS의 SSHFP 레코드로 올리게 함. 이후 SSH 클라이언트가 SSHFP 레코드를 자동 검증하게 할 수 있으며, DNS 영역은 DNSSEC 서명이 되어 있어야 함
이 흐름은 서버가 비공개 SSH 호스트 키를 유지하면서도 키 회전을 피할 수 있게 해줌. 대부분의 DNS 제공자는 이런 세밀한 일회용 접근 토큰을 지원하지 않지만, 토큰을 검증한 뒤 영구적이고 범위 제한 없는 토큰으로 대신 API 호출을 해주는 간단한 내부 웹 서비스를 둘 수 있음. SSH 서버는 그 영구 토큰에 접근하지 못함
창의적인 방식이고, 커스텀 서비스용 일회용 토큰이면 꽤 유연해서 잘 동작할 듯함
다만 DNSSEC 도메인에 쓰기보다는 SSH 인증서를 생성하는 쪽을 더 선호할 것 같고, 그 지점부터는 어떤 해법이 특정 환경에 더 잘 맞는지의 문제가 됨
이렇게 유연한 토큰을 생성할 수 있는 소프트웨어나 제공자를 알고 있는지, 아니면 어느 정도 직접 개발이 필요한지 궁금함
꽤 깔끔함. 그런데 글의 날짜에서 월과 일이 뒤바뀐 것 같음
OpenSSH로 작업하는 건 늘 즐겁고, 월/일 표기는 고쳐 둠
예전에 같은 SSH 닭과 달걀 문제를 탐색하려고 실험적인 서비스를 만든 적이 있음
요청 시 SSHFP DNS 레코드를 생성해 주며, 관심 있으면 https://github.com/tedb/sshfp 를 보면 됨
VM 제공자들 사이에서 어느 정도 일관적인 169.254.169.254 메타데이터 서비스를 다뤄줘서 반가움. cloud-init 소스의 여러 cloudinit/source/DataSource*.py 항목을 보면 확인할 수 있음
개인적으로는 cloud-init의 설계와 한계 때문에 점점 피로감을 느낌. 로컬 QEMU 가상머신, 원격 머신, 컨테이너, 물리 하드웨어 전반에서 시스템 설정을 통합하는 데 관심이 있음 arch-boxes project는 ArchLinux cloud-init image가 어떻게 만들어지는지 보여주며, 매우 단순한 셸 스크립트 묶음임. 이 방법을 guestfish나 µvm으로 응용하면, OCI 호환 이미지, QEMU나 클라우드 제공자용 디스크 이미지, 새 물리 머신 프로비저닝에 완전히 같은 스크립트를 쓸 수 있음
몇 가지 QEMU 플래그와 함께라면 cloud-init 의존 없이 같은 접근을 재현할 수 있음. 아는 한 systemd.system-credentials로 임시 호스트 키를 전달할 수는 없고, ssh.authorized_keys.root 같은 ~/.ssh/authorized_keys용 자격 증명만 있음
대신 initrd 단계에서 실행되거나 systemd-firstboot.service와 함께 실행되는 unit 파일을 만들 수 있음. 이 unit 파일은 이미지에 미리 넣거나 systemd.extra-unit.* 자격 증명으로 임시 주입하고, systemd.wants=… 커널 명령줄 옵션으로 활성화할 수 있음. QEMU에서는 -netdev user,id=metadata,net=169.254.0.0/16,dhcpstart=169.254.0.15,guestfwd=tcp:169.254.169.254:80-cmd:… 항목으로 메타데이터 서비스 존재를 흉내낼 수 있음. 다만 생성된 인터페이스를 활성화해야 할 가능성이 크고, 이 역시 임시 unit 파일로 처리하는 편이 나을 수 있음
이렇게 하면 여러 종류의 “머신”에서 일관된 시스템 설정을 수행할 때, 비교적 낮은 복잡도로 상당한 유연성을 얻음. 실제로 이 작업만 놓고 보면, 이미지 생성 도구가 고정 호스트 키가 들어간 머신 이미지를 만들고, 첫 재부팅이나 종료 때 실행되는 커스텀 호스트 키 회전 스크립트를 SystemD 서비스로 설치하는 방식이 가장 좋아 보임
ArchLinux에서는 /etc/mkinitcpio.conf에서 systemdHOOK을 활성화하면, initrd에서 수행할 작업을 위해 SystemD unit 파일을 작성할 수 있고 사실상 그래야 함
실제로 써보면 {/etc,/usr/lib}/initcpio/hooks를 작성하는 것보다 아주 약간 더 번거로운 정도임
하지만 initrd에서 systemd-networking과 systemd-resolved를 켜는 건 꽤 쉽기 때문에, initrd가 시스템 시작 책임을 맡고 루트 파일시스템으로 전환하기 전에 작업을 예약할 수 있음
물론 노트북 같은 물리 하드웨어에서는 Wi-Fi 연결에 NetworkManager 같은 것이 필요해 잘 안 맞을 수 있지만, QEMU VM과 호스팅 VM에는 잘 맞고 많은 시스템 시작 작업이 이 공간에 자연스럽게 들어감
목표는 cloud-init에 의존하지 않고, 특정 클라우드 제공자 하나에 묶이지 않으며, 물리 머신·컨테이너·로컬 VM·호스팅 VM 전반의 일관성을 얻고, 의존성을 사실상 SystemD 정도로 줄이는 것임
Lobste.rs 의견들
자동화할 수 있어서 멋짐. 수동 방식으로는 클라우드 제공자 콘솔에서 서버의 SSH 지문을 별도 채널로 확인해 왔음
관리하는 클라우드 인스턴스가 많지 않아서, 프로비저닝에 수동 단계가 몇 개 있어도 괜찮음
DNS 영역을 자동화해 뒀다면 다른 접근도 가능함: 범위가 매우 좁은 일회용 토큰을 만들고, 예를 들어
my-server-hostname.example.net에 레코드 하나 생성만 허용하게 함그 토큰을
cloud-init으로 서버에 전달하고, 서버가 공개 SSH 키를 DNS의 SSHFP 레코드로 올리게 함. 이후 SSH 클라이언트가 SSHFP 레코드를 자동 검증하게 할 수 있으며, DNS 영역은 DNSSEC 서명이 되어 있어야 함이 흐름은 서버가 비공개 SSH 호스트 키를 유지하면서도 키 회전을 피할 수 있게 해줌. 대부분의 DNS 제공자는 이런 세밀한 일회용 접근 토큰을 지원하지 않지만, 토큰을 검증한 뒤 영구적이고 범위 제한 없는 토큰으로 대신 API 호출을 해주는 간단한 내부 웹 서비스를 둘 수 있음. SSH 서버는 그 영구 토큰에 접근하지 못함
다만 DNSSEC 도메인에 쓰기보다는 SSH 인증서를 생성하는 쪽을 더 선호할 것 같고, 그 지점부터는 어떤 해법이 특정 환경에 더 잘 맞는지의 문제가 됨
이렇게 유연한 토큰을 생성할 수 있는 소프트웨어나 제공자를 알고 있는지, 아니면 어느 정도 직접 개발이 필요한지 궁금함
꽤 깔끔함. 그런데 글의 날짜에서 월과 일이 뒤바뀐 것 같음
예전에 같은 SSH 닭과 달걀 문제를 탐색하려고 실험적인 서비스를 만든 적이 있음
요청 시 SSHFP DNS 레코드를 생성해 주며, 관심 있으면 https://github.com/tedb/sshfp 를 보면 됨
VM 제공자들 사이에서 어느 정도 일관적인 169.254.169.254 메타데이터 서비스를 다뤄줘서 반가움.
cloud-init소스의 여러cloudinit/source/DataSource*.py항목을 보면 확인할 수 있음개인적으로는
cloud-init의 설계와 한계 때문에 점점 피로감을 느낌. 로컬 QEMU 가상머신, 원격 머신, 컨테이너, 물리 하드웨어 전반에서 시스템 설정을 통합하는 데 관심이 있음arch-boxes project는 ArchLinux cloud-init image가 어떻게 만들어지는지 보여주며, 매우 단순한 셸 스크립트 묶음임. 이 방법을
guestfish나 µvm으로 응용하면, OCI 호환 이미지, QEMU나 클라우드 제공자용 디스크 이미지, 새 물리 머신 프로비저닝에 완전히 같은 스크립트를 쓸 수 있음몇 가지 QEMU 플래그와 함께라면
cloud-init의존 없이 같은 접근을 재현할 수 있음. 아는 한systemd.system-credentials로 임시 호스트 키를 전달할 수는 없고,ssh.authorized_keys.root같은~/.ssh/authorized_keys용 자격 증명만 있음대신 initrd 단계에서 실행되거나
systemd-firstboot.service와 함께 실행되는 unit 파일을 만들 수 있음. 이 unit 파일은 이미지에 미리 넣거나systemd.extra-unit.*자격 증명으로 임시 주입하고,systemd.wants=…커널 명령줄 옵션으로 활성화할 수 있음. QEMU에서는-netdev user,id=metadata,net=169.254.0.0/16,dhcpstart=169.254.0.15,guestfwd=tcp:169.254.169.254:80-cmd:…항목으로 메타데이터 서비스 존재를 흉내낼 수 있음. 다만 생성된 인터페이스를 활성화해야 할 가능성이 크고, 이 역시 임시 unit 파일로 처리하는 편이 나을 수 있음이렇게 하면 여러 종류의 “머신”에서 일관된 시스템 설정을 수행할 때, 비교적 낮은 복잡도로 상당한 유연성을 얻음. 실제로 이 작업만 놓고 보면, 이미지 생성 도구가 고정 호스트 키가 들어간 머신 이미지를 만들고, 첫 재부팅이나 종료 때 실행되는 커스텀 호스트 키 회전 스크립트를 SystemD 서비스로 설치하는 방식이 가장 좋아 보임
/etc/mkinitcpio.conf에서systemdHOOK을 활성화하면, initrd에서 수행할 작업을 위해 SystemD unit 파일을 작성할 수 있고 사실상 그래야 함실제로 써보면
{/etc,/usr/lib}/initcpio/hooks를 작성하는 것보다 아주 약간 더 번거로운 정도임하지만 initrd에서
systemd-networking과systemd-resolved를 켜는 건 꽤 쉽기 때문에, initrd가 시스템 시작 책임을 맡고 루트 파일시스템으로 전환하기 전에 작업을 예약할 수 있음물론 노트북 같은 물리 하드웨어에서는 Wi-Fi 연결에
NetworkManager같은 것이 필요해 잘 안 맞을 수 있지만, QEMU VM과 호스팅 VM에는 잘 맞고 많은 시스템 시작 작업이 이 공간에 자연스럽게 들어감목표는
cloud-init에 의존하지 않고, 특정 클라우드 제공자 하나에 묶이지 않으며, 물리 머신·컨테이너·로컬 VM·호스팅 VM 전반의 일관성을 얻고, 의존성을 사실상 SystemD 정도로 줄이는 것임