Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 2개 있습니다.)
개발 환경 구성: 753. CentOS 7 컨테이너 내에서 openssh 서버 호스팅
; https://www.sysnet.pe.kr/2/0/13982

개발 환경 구성: 754. Visual C++ - 리눅스 빌드를 위한 Ubuntu 18 docker 컨테이너 설정
; https://www.sysnet.pe.kr/2/0/13995




Visual C++ - 리눅스 빌드를 위한 Ubuntu 18 docker 컨테이너 설정

자, 그럼 지난 글까지 해서 ssh 서버를 호스팅할 수 있는 CentOS 7 컨테이너를 위한 Dockerfile도 만들었으니,

CentOS 7 컨테이너 내에서 openssh 서버 호스팅
; https://www.sysnet.pe.kr/2/0/13982

유사한 방식으로 Ubuntu 18 컨테이너를 위한 Dockerfile도 다음과 같이 작성할 수 있습니다.

$ cat ubuntu18.dockerfile
FROM ubuntu:18.04

RUN echo 'root:my_temp_pass' | chpasswd

COPY ./ssh /etc/ssh

RUN apt update && apt upgrade -y
RUN apt install openssh-server -y

RUN sed -ri 's/#?PermitRootLogin\s.*$/PermitRootLogin yes/' /etc/ssh/sshd_config

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

이후 실행은 다 아는 방식대로 해주면 됩니다.

// 이미지 만들고,
$ docker build -f ./ubuntu18.dockerfile . -t ubuntu18_dotnet_img

// 컨테이너 실행 (1)
$ docker run --rm -it --name ubuntu18_dotnet_test -p 16022:22 ubuntu18_dotnet_img /bin/bash
$ docker exec -it ubuntu18_dotnet_test /bin/bash
# /usr/sbin/sshd -D

// 컨테이너 실행 (2)
$ docker run --rm -d --name ubuntu18_dotnet_test -p 16022:22 ubuntu18_dotnet_img

$ docker stop ubuntu18_dotnet_test

그런데 Ubuntu 18 컨테이너에서 /usr/sbin/sshd를 실행하면 이런 오류가 발생합니다.

# /usr/sbin/sshd
Missing privilege separation directory: /run/sshd

다행히 아래의 글에 해결책이 있는데요,

SSH failed to start - Missing privilege separation directory: /var/run/sshd [duplicate]
; https://askubuntu.com/questions/1110828/ssh-failed-to-start-missing-privilege-separation-directory-var-run-sshd

미리 sshd 디렉터리를 생성하면 해결이 됩니다.

$ cat ubuntu18.dockerfile
...[생략]...

RUN apt install openssh-server -y

mkdir /var/run/sshd
chmod 0755 /var/run/sshd

...[생략]...

여기까지 반영해 컨테이너를 실행한 다음, 잘 동작하고 있는지 ssh 클라이언트로 접속해 확인까지 완료합니다.

C:\temp> ssh root@192.168.100.50 -p 16022
root@192.168.100.50's password:
Last login: Wed Jul 30 05:33:18 2025 from 192.168.100.20
[root@287641100cd3 ~]#




이 상태에서 Visual C++의 리눅스 빌드를 위한 환경도 마저 구성해 볼 텐데요, 단순히 (Visual C++ 프로젝트에 설정한 Platform Toolset 유형에 따라) clang 또는 g++ 도구를 설치하는 것으로 완료됩니다.

...[생략]...
RUN apt install clang -y
RUN apt install g++ gdb make -y
...[생략]...

바뀐 설정을 반영해 컨테이너를 실행한 다음, 비주얼 스튜디오 측에서는 2개의 변경을 해야 하는데요, 우선 1) Visual Studio의 Tools / Options 창을 통해 "Cross Platform" - "Connection Manager"에서 "Add" 버튼을 눌러 위에서 만든 컨테이너에 대한 연결 정보를 추가합니다. 2) 그다음, Visual C++ 프로젝트의 속성에서 "Remote Build Machine" 설정란에 Connection Manager에서 추가한 연결 정보를 선택합니다.

여기서 재미있는 것은, 저렇게 Visual Studio에서 바꾼 연결 정보는 (vcxproj 파일이 아닌) 형상 관리와 연동하지 않는 *.vcxproj.user 파일에 저장된다는 점입니다. 이로 인해, 버전 관리 서버로부터 받아 빌드하는 서버에서는 Connection Manager를 통해 연결 정보를 새롭게 추가해야 합니다.

C:\temp> ConnectionManager.exe add root@192.168.100.50 --port 16022

C:\temp> ConnectionManager.exe list
Reading stored connections from '%USERPROFILE%\AppData\Local\Microsoft\Linux\User Data\3.0\store.xml'

Connection ID |            Host | Username | Port | Authentication Type
-----------------------------------------------------------------------
  -1782994236 |  192.168.100.50 |     root | 16022 | Password

그리고 또 하나의 문제는, 저 연결 정보 또한 store.xml에 저장하는 것일 뿐, vcxproj 파일에는 -1782994236 ID의 연결 정보를 이용해 빌드하라는 어떠한 속성도 가지고 있지 않아 마찬가지로 빌드에 실패할 수 있습니다. 테스트해 보면, 빌드 대상의 platform에 해당하는 연결 정보가 하나만 있다면 자동 선택되지만 다중으로 있는 경우에는 (규칙은 알 수 없지만) 특정 연결 정보가 임의로 선택되기 때문에 빌드에 실패할 수 있습니다.

이런 경우, store.xml에 등록된 특정 연결 정보를 선택하도록 msbuild 인자에 /p:RemoteTarget 옵션으로 전달할 수 있습니다. 예를 들어, 완벽하게 모든 정보를 전달해도 되지만,

msbuild.exe testapp.vcxproj /p:RemoteTarget="-1782994236;192.168.100.50 (username=, port=16022, authentication=Password)" /p:Platform=x64;Configuration=Release /t:Rebuild

Connection ID 값만 전달해도 충분하므로 간단하게 다음과 같이 설정할 수 있습니다.

msbuild.exe testapp.vcxproj /p:RemoteTarget="-1782994236" /p:Platform=x64;Configuration=Release /t:Rebuild




혹시 openssh-server 설치 시 이런 질문 단계가 나온다면?

// 미리 /etc/ssh에 키 파일을 복사한 후,

$ apt install openssh-server -y
...[생략]...
Configuration file '/etc/ssh/moduli'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** moduli (Y/I/N/O/D/Z) [default=N] ?
Progress: [ 94%] [####################################################################################################.......]

현재 /etc/ssh 디렉터리에 키 파일은 물론이고 moduli 파일도 있는 상태에서 설치했기 때문입니다. 따라서, 위와 같은 질문이 나오면 덮어쓰면 되고, 혹은 미리 /etc/ssh/moduli 파일을 삭제하면 저런 질문이 나오지 않습니다.




정리해 보면, dockerfile은 대충 이런 식으로 구성할 수 있습니다.

FROM ubuntu:18.04

RUN echo 'root:my_temp_pass' | chpasswd

COPY ./ssh /etc/ssh

RUN apt update && apt upgrade -y
RUN apt install openssh-server unzip curl net-tools lsb-release -y
RUN apt install clang -y
RUN apt install g++ gdb make -y

RUN mkdir /var/run/sshd
RUN chmod 0755 /var/run/sshd

RUN sed -ri 's/#?PermitRootLogin\s.*$/PermitRootLogin yes/' /etc/ssh/sshd_config

EXPOSE 22

CMD ["/usr/sbin/sshd", "-D"]

그렇다면, 혹시나 왜 굳이 최신 버전의 Ubuntu가 아닌 18.04 버전을 사용하는가 궁금할 수 있는데요, 그 이유는 빌드한 바이너리의 호환성을 높이기 위해서입니다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/13/2025]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
12113정성태1/12/202024566오류 유형: 590. Visual C++ 빌드 오류 - fatal error LNK1104: cannot open file 'atls.lib' [1]
12112정성태1/12/202018615오류 유형: 589. PowerShell - 원격 Invoke-Command 실행 시 "WinRM cannot complete the operation" 오류 발생
12111정성태1/12/202022564디버깅 기술: 155. C# - KernelMemoryIO 드라이버를 이용해 실행 프로그램을 숨기는 방법(DKOM: Direct Kernel Object Modification) [16]파일 다운로드1
12110정성태1/11/202023830디버깅 기술: 154. Patch Guard로 인해 블루 스크린(BSOD)가 발생하는 사례 [5]파일 다운로드1
12109정성태1/10/202019035오류 유형: 588. Driver 프로젝트 빌드 오류 - Inf2Cat error -2: "Inf2Cat, signability test failed."
12108정성태1/10/202020359오류 유형: 587. Kernel Driver 시작 시 127(The specified procedure could not be found.) 오류 메시지 발생
12107정성태1/10/202022396.NET Framework: 877. C# - 프로세스의 모든 핸들을 열람 - 두 번째 이야기
12106정성태1/8/202021650VC++: 136. C++ - OSR Driver Loader와 같은 Legacy 커널 드라이버 설치 프로그램 제작 [1]
12105정성태1/8/202020158디버깅 기술: 153. C# - PEB를 조작해 로드된 DLL을 숨기는 방법
12104정성태1/7/202023070DDK: 9. 커널 메모리를 읽고 쓰는 NT Legacy driver와 C# 클라이언트 프로그램 [4]
12103정성태1/7/202026245DDK: 8. Visual Studio 2019 + WDK Legacy Driver 제작- Hello World 예제 [1]파일 다운로드2
12102정성태1/6/202020916디버깅 기술: 152. User 권한(Ring 3)의 프로그램에서 _ETHREAD 주소(및 커널 메모리를 읽을 수 있다면 _EPROCESS 주소) 구하는 방법
12101정성태1/5/202023031.NET Framework: 876. C# - PEB(Process Environment Block)를 통해 로드된 모듈 목록 열람
12100정성태1/3/202020385.NET Framework: 875. .NET 3.5 이하에서 IntPtr.Add 사용
12099정성태1/3/202023267디버깅 기술: 151. Windows 10 - Process Explorer로 확인한 Handle 정보를 windbg에서 조회 [1]
12098정성태1/2/202022772.NET Framework: 874. C# - 커널 구조체의 Offset 값을 하드 코딩하지 않고 사용하는 방법 [3]
12097정성태1/2/202020390디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태12/30/201921882디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작 [1]
12095정성태12/27/201924762VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/201923203.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/201922175.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/201919851디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/201923982디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일 [1]
12090정성태12/24/201923498.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점 [1]파일 다운로드1
12089정성태12/23/201921077디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/201920814Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
... [76]  77  78  79  80  81  82  83  84  85  86  87  88  89  90  ...