macOS Tahoe 26.3로 SSH가 중단됨: 대소문자 구분 변경, DSA 키 지원 중단 및 완전 수정 가이드

Q: RSA 키도 작동을 멈추나요?

SHA-2 서명(rsa-sha2-256 및 rsa-sha2-512)을 사용하는 RSA 키는 계속 작동하며 예상 가능한 미래에도 지원됩니다. 그러나 SHA-1 서명(ssh-rsa)을 사용하는 RSA 키는 OpenSSH 8.8부터 기본으로 비활성화되었으며 향후 버전에서 완전히 제거될 가능성이 높습니다. RSA 키를 사용하는 경우 최소 3072비트인지, 서버가 SHA-2 서명을 수락하는지 확인하세요. 새 키의 경우 Ed25519가 선호되는 선택입니다.

Q: SFTP 및 SCP에도 영향을 미치나요?

네. sftp와 scp는 모두 동일한 SSH 클라이언트 라이브러리를 사용하며 동일한 대소문자 구분 강제 및 DSA 제거의 적용을 받습니다. 시스템 SSH 바이너리를 사용하는 SFTP 클라이언트(Cyberduck, Transmit 또는 FileZilla 등)도 영향을 받습니다. 자체 SSH 라이브러리를 번들하는 GUI SFTP 클라이언트(자체 libssh2 빌드를 사용하는 Cyberduck 등)는 영향을 받지 않을 수 있지만, 이는 특정 애플리케이션에 따라 다릅니다.

macOS Tahoe 26.3은 SSH 사용자 이름 처리를 대소문자 구분으로 조용히 변경하고 ssh-dss 키를 비활성화했습니다. SSH 연결 수정, 구성 업데이트, Ed25519 키 마이그레이션을 위한 완전한 가이드입니다.

Apple은 2026년 2월 11일 macOS Tahoe 26.3을 출시했으며, 수천 명의 개발자와 시스템 관리자에게 SSH 연결이 즉시 중단되었습니다. 경고 대화 상자도 없었습니다. 마이그레이션 도우미도 없었습니다. 이를 언급하는 릴리스 노트도 없었습니다. 어느 날은 ssh administrator@yourserver를 사용할 수 있었는데 다음 날에는 Connection closed by 10.10.83.28 port 22가 표시되었습니다. 레거시 인프라에 대한 인증에 DSA 키를 사용했다면, 해당 키들은 완전히 작동을 멈췄습니다. 이 가이드는 무엇이 변경되었는지, 왜 그런 일이 발생했는지, 그리고 대화형 세션부터 자동화된 CI/CD 파이프라인까지 영향 받는 모든 워크플로우를 수정하는 방법을 자세히 설명합니다.

핵심 요점

macOS Tahoe 26.3은 대소문자를 구분하는 SSH 사용자 이름을 강제합니다. Administrator 대신 administrator를 입력하면 비밀번호 프롬프트 없이 연결이 즉시 닫힙니다.
ssh-dss(DSA) 키가 영구적으로 제거되었습니다. Tahoe 26.3과 함께 번들된 OpenSSH 10.0은 컴파일 시 DSA 지원을 완전히 제거했습니다. 다시 활성화할 구성 플래그가 없습니다.
mlkem768x25519-sha256 또는 sntrup761x25519-sha512를 지원하지 않는 서버에 연결할 때 포스트 양자 키 교환 경고가 표시됩니다.
Ed25519는 모든 새 SSH 키에 권장되는 키 유형입니다. RSA보다 빠르고, 더 안전하며, 더 작은 서명을 생성합니다.
모든 ~/.ssh/config 파일을 감사해야 합니다. User 지시어의 대소문자 불일치와 HostKeyAlgorithms 또는 PubkeyAcceptedAlgorithms의 ssh-dss 참조를 확인하세요.

macOS Tahoe 26.3 SSH에서 정확히 무엇이 변경되었나
업데이트 후 SSH 연결 실패 진단
대소문자 구분 변경 이해하기
DSA 키 제거 이해하기
포스트 양자 키 교환 경고
단계별 수정: 대소문자 구분 문제
단계별 수정: DSA에서 Ed25519로 마이그레이션
완전한 SSH 구성 감사 가이드
SSH 에이전트 변경 및 키체인 통합
CI/CD 파이프라인 및 자동화에 미치는 영향
원격 개발 워크플로우에 미치는 영향
레거시 인프라를 위한 해결 방법
2026년 SSH 보안 모범 사례
자주 묻는 질문
결론

macOS Tahoe 26.3 SSH에서 정확히 무엇이 변경되었나

macOS Tahoe 26.3은 OpenSSH 10.0과 함께 제공되며, 일상적인 SSH 워크플로우에 영향을 미치는 세 가지 주요 변경 사항이 도입됩니다. Apple은 사용자 대상 릴리스 노트에서 이 중 어느 것도 강조하지 않아, 개발자들이 연결 실패를 통해 이를 발견하게 되었습니다.

변경 사항 1: 대소문자를 구분하는 사용자 이름 매칭

Tahoe 26.3 이전에는 macOS의 SSH 클라이언트가 사용자 이름 대소문자에 대해 허용적이었습니다. ssh administrator@server, ssh Administrator@server 또는 ssh ADMINISTRATOR@server로 연결할 수 있었으며, 기본 운영 체제가 계정을 찾을 수 있는 한 원격 서버가 사용자 이름을 올바르게 확인했습니다. 업데이트 후에는 SSH 클라이언트가 연결이 완전히 확립되기 전에 엄격한 대소문자 매칭을 적용합니다. 원격 서버가 기대하는 것과 대소문자가 일치하지 않으면, 비밀번호 인증이나 키 교환이 완료되기 전에 연결이 즉시 닫힙니다.

변경 사항 2: DSA(ssh-dss)의 완전한 제거

OpenSSH는 2015년 버전 7.0부터 DSA를 지원 중단해 왔습니다. 지원 중단은 명확한 타임라인을 따랐습니다:

날짜	OpenSSH 버전	DSA 상태
2015	7.0	기본 비활성화, 구성으로 재활성화 가능
2024	9.x	컴파일 시 선택 사항, 기본 활성화
2024년 중반	9.x	컴파일 시 선택 사항, 기본 비활성화
2025년 4월	10.0	코드베이스에서 완전히 제거
2026년 2월	10.0(macOS Tahoe 26.3)	모든 macOS 사용자에게 배포

macOS Tahoe 26.3에서는 PubkeyAcceptedAlgorithms +ssh-dss 해결 방법이 없습니다. 알고리즘이 바이너리에 존재하지 않습니다. ssh-dss를 참조하는 모든 SSH 구성은 Bad key types 오류를 생성합니다.

변경 사항 3: 포스트 양자 키 교환 경고

OpenSSH 10.0은 포스트 양자 키 교환 알고리즘을 지원하지 않는 서버에 연결할 때 트리거되는 경고를 도입했습니다. 경고 내용은 다음과 같습니다:

WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to 'store now, decrypt later' attacks.

이것은 하드한 실패가 아닌 경고지만, 터미널 출력에 노이즈를 생성하고 SSH 출력을 파싱하는 자동화 스크립트를 중단시킬 수 있습니다.

변경되지 않은 것

변경되지 않은 것을 주목할 가치가 있습니다:

RSA 키는 계속 작동합니다(rsa-sha2-256 및 rsa-sha2-512 서명 알고리즘 포함)
ECDSA 키는 계속 작동합니다(Ed25519가 선호되지만)
SSH 포트 포워딩, 터널링, ProxyJump는 모두 동일하게 작동합니다
~/.ssh/known_hosts 파일 형식은 변경되지 않았습니다

macOS에서 SSH를 처음 사용하거나 처음부터 개발 환경을 설정하는 경우, macOS Tahoe 개발자 설정 가이드에서 전체 초기 구성을 다룹니다.

업데이트 후 SSH 연결 실패 진단

변경을 수행하기 전에, 세 가지 문제 중 어느 것이 연결에 영향을 미치는지 확인해야 합니다. SSH의 상세 출력이 주요 진단 도구입니다.

1단계: 상세 SSH 출력 활성화

실패한 SSH 명령을 삼중 상세 플래그로 실행하여 전체 핸드셰이크 협상을 확인합니다:

ssh -vvv user@hostname

이렇게 하면 연결의 각 단계를 보여주는 상세 출력이 생성됩니다. 다음과 같은 특정 패턴을 찾으세요:

대소문자 구분 실패 패턴:

debug1: Connecting to 10.10.83.28 [10.10.83.28] port 22.
debug1: Connection established.
debug1: identity file /Users/you/.ssh/id_ed25519 type 3
debug3: receive packet: type 7
Connection closed by 10.10.83.28 port 22

핵심 지표는 연결이 확립된 후, 인증 시도 전에 닫힌다는 것입니다. "Permission denied" 메시지가 없으며, 연결이 단순히 끊어집니다.

DSA 키 실패 패턴:

/Users/you/.ssh/config line 15: Bad key types '+ssh-dss'.

또는:

Bad key types '+ssh-rsa,ssh-dss'

이 오류는 SSH 클라이언트가 구성 파일을 파싱할 때 즉시 나타납니다. 연결 시도 전입니다.

포스트 양자 경고 패턴:

WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to 'store now, decrypt later' attacks.

이것은 키 교환 중에 나타나지만 연결 완료를 방해하지 않습니다.

2단계: SSH 클라이언트 버전 확인

어떤 OpenSSH 버전이 실행 중인지 확인합니다:

ssh -V

macOS Tahoe 26.3에서 예상되는 출력:

OpenSSH_10.0p1, LibreSSL 3.3.6

이전 버전이 표시된다면, Homebrew로 설치된 OpenSSH가 우선순위를 차지하고 있을 수 있습니다. 어떤 바이너리가 사용되고 있는지 확인합니다:

which ssh

시스템 SSH는 /usr/bin/ssh에 있습니다. /opt/homebrew/bin/ssh 또는 /usr/local/bin/ssh가 표시되면, 다르게 동작할 수 있는 Homebrew 버전을 사용하고 있는 것입니다.

3단계: 명시적 매개변수로 테스트

명시적인 사용자 이름 대소문자 및 키 유형으로 테스트하여 문제를 격리합니다:

# 대소문자 구분 테스트 - 두 가지 경우를 모두 시도
ssh -vvv Administrator@hostname
ssh -vvv administrator@hostname

# 구성 파일 간섭 없이 테스트
ssh -F /dev/null -vvv user@hostname

# 특정 키로 테스트
ssh -vvv -i ~/.ssh/id_ed25519 user@hostname

터미널 SSH 디버그 출력

4단계: 오류에 대한 SSH 구성 검토

구성 파일을 파싱하여 사용 중단된 알고리즘을 참조하는 줄을 식별합니다:

# ssh-dss 참조 확인
grep -n "ssh-dss" ~/.ssh/config

# 시스템 구성에서 ssh-dss 참조 확인
grep -n "ssh-dss" /etc/ssh/ssh_config

# 대소문자 검토를 위한 모든 User 지시어 확인
grep -n "User " ~/.ssh/config

macOS Tahoe에서의 터미널 사용에 대한 자세한 이해는 macOS Tahoe 터미널 가이드를 참조하세요.

대소문자 구분 변경 이해하기

이 변경이 연결을 중단시키는 이유

대부분의 Unix 계열 시스템에서 사용자 이름은 운영 체제 수준에서 대소문자를 구분합니다. Administrator라는 이름의 사용자는 기술적으로 administrator와 다른 계정입니다. 그러나 SSH 프로토콜 자체(RFC 4252)는 사용자 이름이 "대소문자를 구분한다"고 명시하지만 서버 구현이 이를 다르게 처리할 수 있다고 인정합니다.

macOS Tahoe 26.3 이전에는 macOS SSH 클라이언트가 허용적이었습니다. ssh administrator@server를 입력하면 클라이언트가 사용자 이름을 그대로 전송했고, 많은 SSH 서버(특히 Windows, macOS 또는 네트워크 어플라이언스에서 실행되는 서버)는 인증 중에 대소문자를 정규화했습니다. 서버가 administrator를 Administrator 계정과 매칭하는 작업을 수행했기 때문에 연결이 성공했습니다.

OpenSSH 10.0에서는 macOS의 SSH 클라이언트가 더 엄격한 인증 전 확인을 수행합니다. 서버가 대소문자 불일치를 나타내는 초기 프로토콜 메시지를 반환하면, 인증이 진행되기 전에 연결이 종료됩니다. 이는 다음을 의미합니다:

Windows 서버에 대한 연결(역사적으로 대소문자를 정규화했던)이 중단될 수 있습니다
네트워크 어플라이언스에 대한 연결(라우터, 스위치, NAS 장치)이 대소문자를 구분하지 않는 사용자 이름을 사용하는 경우 중단될 수 있습니다
macOS 서버에 대한 연결(관리자 계정이 Administrator(대문자 A)이지만 스크립트가 administrator(소문자 a)를 사용하는 경우)이 중단됩니다
Linux 서버에 대한 연결은 Linux 사용자 이름이 이미 대소문자를 구분하므로 영향을 받을 가능성이 낮습니다

중단되는 일반적인 시나리오

시나리오 1: macOS에서 macOS 원격 관리

많은 시스템 관리자가 다음과 같이 원격 Mac에 연결합니다:

ssh [email protected]

그러나 기본 macOS 관리자 계정은 대문자 A가 있는 Administrator로 생성됩니다. 이것은 Tahoe 26.3 이전에는 작동했지만 이후에는 중단됩니다.

시나리오 2: 네트워크 어플라이언스 관리

라우터, 스위치, 방화벽 및 NAS 장치에 연결하는 경우 일반 사용자 이름을 사용하는 경우가 많습니다:

ssh [email protected]
ssh [email protected]

장치가 사용자 이름을 Admin 또는 ROOT로 저장하는 경우, 이러한 연결은 이제 자동으로 실패합니다.

시나리오 3: SSH 구성 별칭

많은 개발자가 이전에는 작동했던 잘못된 대소문자의 SSH 구성 항목을 가지고 있습니다:

# ~/.ssh/config - 이것이 이제 중단될 수 있습니다
Host production
    HostName prod.example.com
    User deploy      # 서버는 "Deploy"를 기대합니다
    IdentityFile ~/.ssh/prod_key

DSA 키 제거 이해하기

DSA에 반대하는 보안 논거

SSH에서 구현된 DSA(디지털 서명 알고리즘)는 고정 1024비트 키 길이와 해싱을 위한 SHA-1을 사용합니다. 이 조합은 약 80비트의 대칭 보안을 제공하며, 이는 현대 보안 표준에서 권장하는 128비트 최소값보다 훨씬 낮습니다.

DSA 키의 특정 약점:

속성	DSA(ssh-dss)	Ed25519	RSA-4096
키 크기	1024비트	256비트	4096비트
해시 알고리즘	SHA-1	SHA-512	SHA-256/512
보안 수준	~80비트	~128비트	~128비트
서명 크기	40바이트	64바이트	512바이트
서명 속도	느림	빠름	보통
검증 속도	느림	빠름	보통
편향 취약성	높음	없음	없음

DSA는 구현 결함에 특히 취약합니다. 서명 중에 사용되는 난수 생성기에 편향이 있으면 소수의 서명에서 개인 키를 복구할 수 있습니다. 이것은 실제 공격에서 악용되었습니다.

"제거됨"이 실제로 의미하는 것

이전 macOS 버전에서는 DSA가 기본적으로 비활성화되어 있었지만 구성 옵션으로 다시 활성화할 수 있었습니다:

# 이것은 macOS Sequoia 및 이전 버전에서 작동했습니다
Host legacy-server
    HostKeyAlgorithms +ssh-dss
    PubkeyAcceptedAlgorithms +ssh-dss

macOS Tahoe 26.3에서는 SSH 바이너리가 ssh-dss를 유효한 알고리즘 식별자로 더 이상 인식하지 않기 때문에 이러한 구성 줄 자체가 오류를 발생시킵니다. 오류는 다음과 같습니다:

/Users/you/.ssh/config line 8: Bad key types '+ssh-dss'.

이는 다음을 의미합니다:

인증에 DSA 키를 사용할 수 없습니다(공개 키 로그인)
서버의 DSA 호스트 키를 허용할 수 없습니다
구성 파일에서 ssh-dss를 참조하면 오류가 발생합니다
ssh-keygen 도구는 더 이상 DSA 키를 생성할 수 없습니다

DSA 키가 있는지 확인

마이그레이션을 진행하기 전에 기존 키를 확인합니다:

# 모든 SSH 키와 유형 목록
for key in ~/.ssh/*.pub; do
    echo "=== $key ==="
    ssh-keygen -l -f "$key"
done

예제 출력:

=== /Users/you/.ssh/id_dsa.pub ===
1024 SHA256:abc123... you@mac (DSA)          # 이 키는 교체해야 합니다
=== /Users/you/.ssh/id_ed25519.pub ===
256 SHA256:xyz789... you@mac (ED25519)       # 이 키는 괜찮습니다
=== /Users/you/.ssh/id_rsa.pub ===
3072 SHA256:def456... you@mac (RSA)          # 이 키는 괜찮습니다

(DSA)로 식별된 모든 키는 교체해야 합니다. 발견했다면 아직 삭제하지 마세요. 어떤 서버가 이를 승인했는지 확인하는 데 필요합니다.

포스트 양자 키 교환 경고

경고의 의미

OpenSSH 10.0은 X25519와 혼합된 ML-KEM(이전 CRYSTALS-Kyber) 알고리즘을 사용한 포스트 양자 키 교환을 도입했습니다. 기본 키 교환 알고리즘은 이제 mlkem768x25519-sha256이며, sntrup761x25519-sha512가 폴백입니다.

이러한 알고리즘 중 어느 것도 지원하지 않는 서버에 연결하면 OpenSSH가 다음을 표시합니다:

WARNING: connection is not using a post-quantum key exchange algorithm.
This session may be vulnerable to 'store now, decrypt later' attacks.

"지금 저장하고 나중에 복호화" 공격은 적이 오늘 암호화된 SSH 트래픽을 기록하고 양자 컴퓨터가 고전적인 키 교환 알고리즘을 깰 수 있게 될 미래에 이를 복호화할 수 있음을 의미합니다.

이 경고가 표시되는 경우

OpenSSH 8.x 이전을 실행하는 서버에 연결할 때
내장된 SSH 구현을 가진 네트워크 어플라이언스에 연결할 때
이전 SSH 데몬 버전을 가진 클라우드 인스턴스에 연결할 때
GitHub, GitLab 또는 Bitbucket에 연결할 때(아직 PQ 알고리즘을 지원하지 않을 수 있음)

경고 음소거

위험을 이해하고 경고를 억제하려면 ~/.ssh/config에 다음을 추가합니다:

# 포스트 양자 경고를 전역으로 억제
Host *
    WarnWeakCrypto no

또는 특정 호스트에만:

Host legacy-server
    HostName 192.168.1.100
    WarnWeakCrypto no

이상적인 해결 방법은 sntrup761x25519-sha512를 지원하는 OpenSSH 9.0 이상 또는 새로운 mlkem768x25519-sha256을 지원하는 OpenSSH 9.9+로 서버를 업데이트하는 것입니다.

단계별 수정: 대소문자 구분 문제

수정 1: 올바른 사용자 이름 대소문자 확인

먼저 원격 시스템의 정확한 사용자 이름을 확인합니다. 방법은 원격 OS에 따라 다릅니다:

원격 Linux/macOS 서버의 경우:

# 여전히 콘솔, 물리적 접근 또는 다른 SSH 클라이언트를 통해 로그인할 수 있는 경우
grep "your_username" /etc/passwd

# 또는 id 명령 사용
id

# 출력 예: uid=501(Administrator) gid=20(staff) groups=...

원격 Windows 서버(OpenSSH)의 경우:

# 원격 머신의 PowerShell에서
whoami
# 출력: DOMAIN\Administrator

네트워크 어플라이언스의 경우:

정확한 사용자 이름 형식에 대해 장치의 웹 관리 인터페이스나 문서를 확인합니다. 일반적인 패턴:

Cisco IOS: 일반적으로 소문자(admin)
Juniper: 일반적으로 소문자(root)
Synology NAS: 생성된 대로 대소문자 구분
QNAP NAS: 생성된 대로 대소문자 구분

수정 2: SSH 구성 파일 업데이트

SSH 구성을 열고 모든 User 지시어를 수정합니다:

# 구성 파일 열기
nano ~/.ssh/config

수정 전(손상됨):

Host production
    HostName prod.example.com
    User administrator
    IdentityFile ~/.ssh/prod_key

Host nas
    HostName nas.local
    User admin
    Port 22

수정 후(수정됨):

Host production
    HostName prod.example.com
    User Administrator
    IdentityFile ~/.ssh/prod_key

Host nas
    HostName nas.local
    User Admin
    Port 22

수정 3: 셸 별칭 및 스크립트 업데이트

셸 구성에서 SSH 명령을 검색합니다:

# bash 별칭 확인
grep -n "ssh " ~/.bashrc ~/.bash_profile 2>/dev/null

# zsh 별칭 확인
grep -n "ssh " ~/.zshrc ~/.zprofile 2>/dev/null

# 사용자 정의 스크립트의 SSH 명령 확인
grep -rn "ssh " ~/scripts/ ~/bin/ 2>/dev/null

하드코딩된 사용자 이름을 올바른 대소문자를 사용하도록 업데이트합니다.

수정 4: 환경 변수 업데이트

일부 도구는 SSH 사용자 이름에 환경 변수를 사용합니다:

# SSH 관련 환경 변수 확인
env | grep -i ssh
env | grep -i user

# 확인할 일반적인 변수
echo $DEPLOY_USER
echo $SSH_USER
echo $REMOTE_USER

수정 5: 수정 확인

변경 후 각 연결을 확인합니다:

# 상세 출력으로 테스트
ssh -v production

# 예상: 인증 성공
# debug1: Authentication succeeded (publickey).

단계별 수정: DSA에서 Ed25519로 마이그레이션

이 섹션에서는 DSA 키를 Ed25519 키로 교체하는 전체 프로세스를 안내합니다. 터미널 명령에 대한 배경 지식이 필요한 경우, Mac 터미널 숙달 가이드에서 모든 기초를 다룹니다.

SSH 키 마이그레이션 흐름

1단계: DSA 키 인벤토리

새 키를 생성하기 전에 DSA 키가 사용되는 위치를 문서화합니다:

# 1단계: 시스템의 모든 DSA 키 찾기
find ~/.ssh -name "*.pub" -exec grep -l "ssh-dss" {} \;

# 2단계: 각 DSA 키에 대해 어떤 서버가 이를 승인하는지 확인
# 공개 키 지문에 주목
ssh-keygen -l -f ~/.ssh/id_dsa.pub

# 3단계: known_hosts에서 DSA 호스트 키 확인
grep "ssh-dss" ~/.ssh/known_hosts | awk '{print $1}'

마이그레이션 체크리스트 생성:

# 마이그레이션 추적 파일 생성
cat > ~/ssh_migration_checklist.txt << 'EOF'
SSH DSA 키 마이그레이션 체크리스트
===============================
날짜: $(date)

발견된 DSA 키:
- [ ] ~/.ssh/id_dsa -> 사용 용도: _______________
- [ ] ~/.ssh/id_dsa.pub -> 승인된 서버: _______________

DSA 호스트 키를 가진 서버:
- [ ] server1.example.com
- [ ] 192.168.1.100

DSA를 사용하는 자동화/스크립트:
- [ ] deploy.sh
- [ ] backup-cron.sh
- [ ] CI/CD 파이프라인: _______________
EOF

2단계: 새 Ed25519 키 생성

의미 있는 주석으로 새 Ed25519 키 쌍을 생성합니다:

# 설명적인 주석으로 Ed25519 키 생성
ssh-keygen -t ed25519 -C "yourname@macbook-2026-02" -f ~/.ssh/id_ed25519

# 패스프레이즈를 입력하라는 메시지가 표시됩니다 - 사용하세요
# 패스프레이즈는 머신이 손상된 경우 개인 키를 보호합니다

다른 용도로 별도의 키가 필요한 경우(보안 격리를 위해 권장):

# 업무 서버용 키
ssh-keygen -t ed25519 -C "work-servers-2026" -f ~/.ssh/id_ed25519_work

# 개인 프로젝트용 키
ssh-keygen -t ed25519 -C "personal-2026" -f ~/.ssh/id_ed25519_personal

# CI/CD 자동화용 키
ssh-keygen -t ed25519 -C "cicd-automation-2026" -f ~/.ssh/id_ed25519_cicd

생성된 키 확인:

# 새 키 확인
ssh-keygen -l -f ~/.ssh/id_ed25519.pub

# 예상 출력:
# 256 SHA256:abcdef123456... yourname@macbook-2026-02 (ED25519)

3단계: 서버에 새 키 배포

이전에 DSA 키를 사용했던 각 서버에 새 Ed25519 공개 키를 배포합니다:

방법 1: ssh-copy-id 사용(아직 인증할 수 있는 경우)

다른 작동하는 인증 방법(비밀번호, 다른 키)이 있는 경우:

# 비밀번호 인증을 사용하여 새 키 배포
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

# 또는 배포 중 인증을 위해 작동하는 키 지정
ssh-copy-id -i ~/.ssh/id_ed25519.pub -o "IdentityFile=~/.ssh/id_rsa" user@server

방법 2: 수동 배포(ssh-copy-id를 사용할 수 없는 경우)

# 공개 키 내용 복사
cat ~/.ssh/id_ed25519.pub | pbcopy

# 작동하는 방법(비밀번호, 콘솔 등)으로 서버에 SSH
ssh user@server

# 원격 서버에서 키 추가
mkdir -p ~/.ssh
chmod 700 ~/.ssh
echo "여기에 공개 키 붙여넣기" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

방법 3: SSH로 접근할 수 없는 서버의 경우

DSA 키가 유일한 인증 방법이고 더 이상 작동하지 않는 경우:

서버의 웹 관리 콘솔 사용(가능한 경우)
물리적 콘솔 또는 IPMI/iLO/iDRAC를 통해 액세스
여전히 접근 권한이 있는 점프 호스트 사용
서버 관리자에게 연락

4단계: SSH 구성 업데이트

SSH 구성에서 DSA 키 참조를 교체합니다:

# 수정 전
Host old-server
    HostName legacy.example.com
    User admin
    IdentityFile ~/.ssh/id_dsa
    HostKeyAlgorithms +ssh-dss
    PubkeyAcceptedAlgorithms +ssh-dss

# 수정 후
Host old-server
    HostName legacy.example.com
    User Admin
    IdentityFile ~/.ssh/id_ed25519_work

5단계: 알려진 호스트 정리

오래된 DSA 호스트 키 항목을 제거합니다:

# known_hosts에서 DSA 호스트 키를 가진 서버 찾기
grep "ssh-dss" ~/.ssh/known_hosts

# 특정 호스트 항목 제거(다음 연결 시 호스트 키가 다시 수락됩니다)
ssh-keygen -R hostname_or_ip

# 또는 모든 DSA 항목을 한 번에 제거
# 먼저 파일 백업
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.backup.$(date +%Y%m%d)

# 그 다음 DSA 항목 제거
grep -v "ssh-dss" ~/.ssh/known_hosts > ~/.ssh/known_hosts.tmp
mv ~/.ssh/known_hosts.tmp ~/.ssh/known_hosts

6단계: 모든 것이 작동하는지 확인

각 서버 연결을 테스트합니다:

# 상세 출력으로 연결 테스트
ssh -v old-server

# 올바른 키가 제공되고 있는지 확인
# 찾을 내용: debug1: Offering public key: /Users/you/.ssh/id_ed25519_work ED25519

# 구성된 모든 호스트에 대한 전체 연결 테스트 실행
for host in $(grep "^Host " ~/.ssh/config | awk '{print $2}' | grep -v '\*'); do
    echo "테스트 중: $host"
    ssh -o ConnectTimeout=5 -o BatchMode=yes "$host" echo "OK" 2>&1
    echo "---"
done

7단계: DSA 키 폐기

모든 서버가 마이그레이션되고 확인되면:

# 이전 DSA 키 보관(즉시 삭제하지 않음)
mkdir -p ~/.ssh/deprecated
mv ~/.ssh/id_dsa ~/.ssh/deprecated/id_dsa.retired.$(date +%Y%m%d)
mv ~/.ssh/id_dsa.pub ~/.ssh/deprecated/id_dsa.pub.retired.$(date +%Y%m%d)
chmod 400 ~/.ssh/deprecated/id_dsa.retired.*

놓친 서버를 발견하는 경우를 대비하여 보관된 키를 최소 90일간 보관하세요.

완전한 SSH 구성 감사 가이드

개별 문제를 해결한 후 SSH 구성에 대한 완전한 감사를 수행합니다. 수년간 macOS에서 SSH를 사용하고 여러 macOS 업그레이드를 거쳐 구성 항목을 누적했다면 특히 중요합니다.

감사 1단계: 사용 중단된 알고리즘 확인

# 사용 중단된 알고리즘 참조 확인
echo "=== ~/.ssh/config 확인 ==="
grep -n -E "(ssh-dss|ssh-dsa|diffie-hellman-group1-sha1|diffie-hellman-group14-sha1|hmac-sha1-96|hmac-md5)" ~/.ssh/config 2>/dev/null

echo ""
echo "=== /etc/ssh/ssh_config 확인 ==="
grep -n -E "(ssh-dss|ssh-dsa|diffie-hellman-group1-sha1)" /etc/ssh/ssh_config 2>/dev/null

echo ""
echo "=== /etc/ssh/ssh_config.d/ 확인 ==="
grep -rn -E "(ssh-dss|ssh-dsa)" /etc/ssh/ssh_config.d/ 2>/dev/null

감사 2단계: 구성 구문 확인

# 연결하지 않고 SSH 구성 구문 테스트
ssh -G test-host 2>&1 | head -5

# 오류가 있으면 다음과 같이 표시됩니다:
# /Users/you/.ssh/config line X: Bad key types '...'

감사 3단계: 모든 User 지시어 검토

# 모든 User 지시어와 적용되는 호스트 추출
awk '/^Host /{host=$2} /User /{print host, $0}' ~/.ssh/config

출력을 검토하고 각 사용자 이름의 대소문자를 확인합니다.

감사 4단계: 파일 권한 확인

SSH는 파일 권한에 엄격합니다. 잘못된 권한은 자동 실패를 야기할 수 있습니다:

# SSH 디렉토리 권한 확인 및 수정
echo "=== 디렉토리 권한 ==="
ls -la ~/.ssh/

echo ""
echo "=== 예상 권한 ==="
echo "~/.ssh/           -> drwx------ (700)"
echo "~/.ssh/config     -> -rw------- (600)"
echo "~/.ssh/id_*       -> -rw------- (600) 개인 키용"
echo "~/.ssh/*.pub      -> -rw-r--r-- (644) 공개 키용"
echo "~/.ssh/authorized_keys -> -rw------- (600)"
echo "~/.ssh/known_hosts     -> -rw-r--r-- (644)"

# 필요한 경우 권한 수정
chmod 700 ~/.ssh
chmod 600 ~/.ssh/config 2>/dev/null
chmod 600 ~/.ssh/id_* 2>/dev/null
chmod 644 ~/.ssh/*.pub 2>/dev/null
chmod 600 ~/.ssh/authorized_keys 2>/dev/null

감사 5단계: 권장되는 최신 SSH 구성 템플릿

macOS Tahoe 26.3에서 작동하는 완전하고 최신의 SSH 구성 템플릿입니다:

# ~/.ssh/config
# macOS Tahoe 26.3 / OpenSSH 10.0용으로 업데이트
# 마지막 감사: 2026-02-28

# ============================================
# 전역 기본값
# ============================================
Host *
    # 기본적으로 Ed25519 키 사용
    IdentityFile ~/.ssh/id_ed25519

    # 각 호스트에 명시적으로 구성된 키만 제공
    IdentitiesOnly yes

    # macOS 키체인 통합
    UseKeychain yes
    AddKeysToAgent yes

    # 최신 키 교환 기본 설정
    KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256,[email protected]

    # 연결 안정성
    ServerAliveInterval 60
    ServerAliveCountMax 3

    # 보안 강화
    HashKnownHosts yes
    StrictHostKeyChecking ask

# ============================================
# 업무 서버
# ============================================
Host prod-web
    HostName prod-web.example.com
    User Deploy
    IdentityFile ~/.ssh/id_ed25519_work
    Port 22

Host staging
    HostName staging.example.com
    User Deploy
    IdentityFile ~/.ssh/id_ed25519_work
    Port 22

# ============================================
# 개인 서버
# ============================================
Host homelab
    HostName 192.168.1.100
    User admin
    IdentityFile ~/.ssh/id_ed25519_personal

# ============================================
# 점프 호스트 구성
# ============================================
Host internal-*
    ProxyJump bastion.example.com
    User admin
    IdentityFile ~/.ssh/id_ed25519_work

Host bastion.example.com
    User jump-user
    IdentityFile ~/.ssh/id_ed25519_work
    ForwardAgent no

SSH 에이전트 변경 및 키체인 통합

macOS Tahoe 26.3은 SSH 에이전트가 macOS 키체인과 상호 작용하는 방식에도 미묘한 변화를 가져옵니다.

키체인 통합

macOS 전용 UseKeychain 지시어는 Tahoe 26.3에서 계속 작동하지만 동작이 개선되었습니다:

# 새 Ed25519 키를 macOS 키체인에 추가
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

# 키가 추가되었는지 확인
ssh-add -l

키가 성공적으로 추가되면 다음이 표시됩니다:

256 SHA256:abcdef123456... yourname@macbook-2026-02 (ED25519)

영구적인 키 로딩

재부팅 후 키 지속성을 유지하려면 SSH 구성에 이러한 지시어가 포함되어 있는지 확인합니다:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

UseKeychain yes가 없으면 매번 재부팅 후 ssh-add를 실행해야 합니다.

SSH 에이전트 확인

# 에이전트가 실행 중인지 확인
echo $SSH_AUTH_SOCK

# 로드된 키 목록
ssh-add -l

# 로드된 키가 없으면 추가
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

macOS 보안 구성에 대한 자세한 내용은 macOS Tahoe 보안 개인 정보 보호 가이드를 참조하세요.

CI/CD 파이프라인 및 자동화에 미치는 영향

macOS Tahoe 26.3의 SSH 변경은 자동화된 워크플로우에 중대한 영향을 미칩니다. CI/CD 파이프라인이 macOS 러너(GitHub Actions, GitLab CI, Mac의 Jenkins)에서 실행되는 경우, 러너 OS가 업그레이드되면 이러한 변경이 영향을 미칩니다.

GitHub Actions

macos-latest 또는 macos-15 러너를 사용하는 경우 SSH 바이너리가 결국 업데이트됩니다. 지금 워크플로우를 감사합니다:

# .github/workflows/deploy.yml
# 수정 전(잠재적으로 손상됨)
- name: Deploy
  run: |
    ssh administrator@${{ secrets.DEPLOY_HOST }} "cd /app && git pull"

# 수정 후(수정됨)
- name: Deploy
  run: |
    ssh Administrator@${{ secrets.DEPLOY_HOST }} "cd /app && git pull"

배포 시크릿을 확인합니다:

DEPLOY_USER: 대소문자가 원격 계정과 일치하는지 확인
SSH_PRIVATE_KEY: DSA 키가 아닌지 확인
KNOWN_HOSTS: DSA 호스트 키 항목이 없는지 확인

GitLab CI

# .gitlab-ci.yml
deploy:
  before_script:
    # 배포 전 키 유형 확인
    - ssh-keygen -l -f ~/.ssh/id_deploy
    # DSA가 아닌지 확인
    - |
      if ssh-keygen -l -f ~/.ssh/id_deploy | grep -q "DSA"; then
        echo "오류: DSA 키가 감지되었습니다. 마이그레이션이 필요합니다."
        exit 1
      fi
  script:
    # 사용자 이름에 올바른 대소문자 사용
    - ssh -o StrictHostKeyChecking=no Deploy@$DEPLOY_HOST "deploy.sh"

Jenkins

macOS 에이전트에서 실행되는 Jenkins 파이프라인의 경우:

pipeline {
    agent { label 'macos' }
    stages {
        stage('Pre-flight SSH Check') {
            steps {
                sh '''
                    # SSH 버전 확인
                    ssh -V

                    # 자격 증명의 DSA 키 확인
                    for key in ~/.ssh/*.pub; do
                        if ssh-keygen -l -f "$key" | grep -q "DSA"; then
                            echo "경고: DSA 키 발견: $key"
                            exit 1
                        fi
                    done

                    echo "SSH 사전 확인 통과"
                '''
            }
        }
    }
}

Ansible Playbooks

macOS 제어 노드에서 Ansible을 실행하는 경우:

# ansible.cfg
[defaults]
# 올바른 SSH 바이너리 확인
ssh_executable = /usr/bin/ssh

# 특정 SSH 인수 강제
[ssh_connection]
ssh_args = -o IdentitiesOnly=yes -o IdentityFile=~/.ssh/id_ed25519_ansible

Ansible 인벤토리에서 사용자 이름 대소문자 확인:

# inventory.ini
# 수정 전
[webservers]
web1.example.com ansible_user=administrator

# 수정 후
[webservers]
web1.example.com ansible_user=Administrator

자동화된 백업 스크립트

SSH를 사용하는 cron 작업 또는 launchd 작업을 검토합니다:

# SSH 참조가 있는 모든 cron 작업 찾기
crontab -l 2>/dev/null | grep -i ssh

# SSH 참조가 있는 launchd plist 찾기
grep -rl "ssh" ~/Library/LaunchAgents/ /Library/LaunchAgents/ /Library/LaunchDaemons/ 2>/dev/null

# rsync 백업 스크립트 확인(rsync는 기본적으로 SSH 사용)
grep -rn "rsync.*@" ~/scripts/ ~/bin/ 2>/dev/null

원격 개발 워크플로우에 미치는 영향

VS Code 원격 SSH

Visual Studio Code의 Remote SSH 확장 프로그램은 영향을 받을 수 있는 연결 구성을 저장합니다:

# VS Code SSH 구성 위치
cat ~/Library/Application\ Support/Code/User/settings.json | grep -A5 "remote.SSH"

# VS Code의 SSH 구성 참조 확인
grep -n "ssh" ~/Library/Application\ Support/Code/User/settings.json 2>/dev/null

올바른 사용자 이름 대소문자와 비DSA 키를 사용하도록 VS Code SSH 대상을 업데이트합니다.

JetBrains Gateway / 원격 개발

JetBrains IDE는 SSH 구성을 별도로 저장합니다:

# JetBrains SSH 구성 확인
find ~/Library/Application\ Support/JetBrains -name "*.xml" -exec grep -l "ssh" {} \; 2>/dev/null

tmux 및 영구 세션

SSH를 통해 tmux 또는 screen을 사용하는 경우 재연결 스크립트를 업데이트해야 합니다:

# 일반적인 tmux 재연결 별칭 - 사용자 이름 대소문자 확인
alias tm='ssh -t Administrator@server "tmux attach || tmux new"'

포괄적인 개발자 환경 설정은 macOS Tahoe 개발자 궁극 가이드를 참조하세요.

레거시 인프라를 위한 해결 방법

일부 환경은 즉시 업데이트할 수 없습니다. 네트워크 어플라이언스, 임베디드 시스템 및 레거시 서버는 수년간 DSA가 필요할 수 있습니다. 가장 권장되는 것부터 가장 덜 권장되는 순서로 실용적인 해결 방법을 제시합니다.

해결 방법 1: 점프 호스트 사용(권장)

DSA를 아직 지원하는 Linux 요새 호스트를 설정하고 프록시로 사용합니다:

# ~/.ssh/config
Host legacy-device
    HostName 192.168.1.1
    User admin
    ProxyJump bastion

Host bastion
    HostName bastion.example.com
    User jump
    IdentityFile ~/.ssh/id_ed25519

요새 호스트는 이전 OpenSSH(또는 DSA 지원으로 컴파일된 것)를 실행하고 레거시 장치와의 DSA 협상을 처리합니다. Mac은 Ed25519를 사용하여 요새에 인증하기만 하면 됩니다.

해결 방법 2: Docker 컨테이너 사용

Docker 컨테이너 내에서 이전 OpenSSH 클라이언트를 실행합니다:

# 레거시 SSH용 Dockerfile 생성
cat > ~/legacy-ssh/Dockerfile << 'EOF'
FROM alpine:3.18
RUN apk add --no-cache openssh-client
ENTRYPOINT ["ssh"]
EOF

# 빌드
docker build -t legacy-ssh ~/legacy-ssh/

# 레거시 장치에 연결하는 데 사용
docker run --rm -it \
    -v ~/.ssh:/root/.ssh:ro \
    legacy-ssh \
    -o HostKeyAlgorithms=+ssh-dss \
    -o PubkeyAcceptedKeyTypes=+ssh-dss \
    admin@legacy-device

편의를 위한 셸 별칭 생성:

# ~/.zshrc에 추가
alias legacy-ssh='docker run --rm -it -v ~/.ssh:/root/.ssh:ro legacy-ssh'

# 사용법
legacy-ssh -o HostKeyAlgorithms=+ssh-dss admin@legacy-device

해결 방법 3: Homebrew를 통해 이전 OpenSSH 설치

소스에서 OpenSSH 9.7p1(DSA 지원이 있는 마지막 버전)을 컴파일할 수 있습니다:

# 종속성 설치
brew install openssl@3

# OpenSSH 9.7p1 소스 다운로드
curl -O https://cdn.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-9.7p1.tar.gz
tar xzf openssh-9.7p1.tar.gz
cd openssh-9.7p1

# DSA 지원 및 사용자 정의 접두사로 구성
./configure \
    --prefix=$HOME/openssh97 \
    --with-ssl-dir=$(brew --prefix openssl@3)

# 빌드 및 설치
make -j$(sysctl -n hw.ncpu)
make install

# 이전 SSH 바이너리 사용
~/openssh97/bin/ssh -o HostKeyAlgorithms=+ssh-dss admin@legacy-device

레거시 연결을 위한 별칭 생성:

# ~/.zshrc에 추가
alias ssh-legacy='~/openssh97/bin/ssh -o HostKeyAlgorithms=+ssh-dss -o PubkeyAcceptedKeyTypes=+ssh-dss'

# 사용법
ssh-legacy admin@old-router

해결 방법 4: Linux 가상 머신 사용

UTM, Parallels 또는 VMware Fusion을 사용하는 경우:

경량 Linux VM(Alpine 또는 Ubuntu Server) 설정
Mac에서 VM으로 SSH 연결(Ed25519 사용)
VM에서 레거시 장치로 SSH 연결(DSA 사용)

이는 완전한 격리를 제공하며 macOS SSH 설치를 수정할 필요가 없습니다.

장기적: 장치 교체 계획

네트워크 어플라이언스가 최신 알고리즘을 지원하지 않기 때문에 DSA에 의존한다면, 그것은 해당 장치들이 보안 관점에서 수명이 다했다는 명확한 신호입니다. 교체 타임라인을 계획합니다:

라우터/스위치: 대부분의 엔터프라이즈 벤더는 2018년부터 Ed25519를 지원합니다
NAS 장치: Synology, QNAP, TrueNAS는 모두 Ed25519를 지원합니다
레거시 서버: OpenSSH 6.5보다 오래된 버전을 실행하는 경우 전체 시스템을 업데이트해야 합니다

2026년 SSH 보안 모범 사례

macOS Tahoe 26.3의 변경을 계기로 포괄적인 SSH 보안 개선을 구현할 좋은 시기입니다.

키 관리 모범 사례

1. 별도의 역할에 별도의 키 사용:

# 업무 인프라
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work-2026"

# 개인 프로젝트
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_personal -C "personal-2026"

# CI/CD 및 자동화
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_automation -C "automation-2026"

# Git 호스팅(GitHub, GitLab)
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_git -C "git-2026"

2. 항상 패스프레이즈 사용:

패스프레이즈는 저장 시 개인 키를 암호화합니다. 머신이 손상된 경우 공격자는 패스프레이즈 없이 SSH 키를 사용할 수 없습니다. macOS 키체인 통합과 결합하면 패스프레이즈를 한 번만 입력하면 됩니다.

# 키 생성 중 메시지가 표시되면:
Enter passphrase (empty for no passphrase): [강력한 패스프레이즈 입력]
Enter same passphrase again: [확인]

3. 연간 키 교체:

언제 생성되었는지 알 수 있도록 키 주석에 연도를 포함합니다:

ssh-keygen -t ed25519 -C "you@company-2026-Q1" -f ~/.ssh/id_ed25519_work_2026

연도가 바뀌면 새 키를 생성하고 배포한 후 이전 키를 폐기합니다.

4. 올바른 파일 권한 설정:

# 개인 키: 소유자 읽기 전용
chmod 400 ~/.ssh/id_ed25519*
chmod 600 ~/.ssh/id_ed25519*.pub

# 실제로 공개 키는 모든 사람이 읽을 수 있습니다
chmod 644 ~/.ssh/id_ed25519*.pub

# SSH 디렉토리 자체
chmod 700 ~/.ssh

# 구성 파일
chmod 600 ~/.ssh/config

서버 측 강화

SSH 서버를 관리하는 경우 이 기회에 강화합니다:

# /etc/ssh/sshd_config 권장 설정

# 비밀번호 인증 비활성화(키만 사용)
PasswordAuthentication no

# root 로그인 비활성화
PermitRootLogin no

# 특정 사용자만 허용
AllowUsers deploy admin

# 최신 키 교환 사용
KexAlgorithms mlkem768x25519-sha256,[email protected],curve25519-sha256

# 최신 호스트 키 알고리즘 사용
HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# 최신 암호화 사용
Ciphers [email protected],[email protected],[email protected]

# 최신 MAC 사용
MACs [email protected],[email protected]

# 속도 제한
MaxAuthTries 3
MaxSessions 5
LoginGraceTime 30

sshd_config를 변경한 후 연결을 끊기 전에 항상 테스트합니다:

# 구성 확인
sudo sshd -t

# 오류가 없으면 sshd 재시작
sudo systemctl restart sshd

# 중요: 현재 세션을 열어 두고 기존 세션을 닫기 전에
# 새 연결로 테스트

모니터링 및 경고

SSH 인증 이벤트에 대한 모니터링을 설정합니다:

# 실패한 시도에 대한 auth.log 모니터링(Linux 서버)
tail -f /var/log/auth.log | grep "sshd"

# SSH 이벤트에 대한 macOS 시스템 로그 모니터링
log stream --predicate 'process == "sshd"' --level info

일반적인 오류 해결

오류: "Connection closed by X.X.X.X port 22"

원인: 사용자 이름 대소문자 불일치.

수정:

# 올바른 사용자 이름 확인
ssh -vvv user@host 2>&1 | grep "debug1: Sending"

# 반대 대소문자 시도
ssh Administrator@host  # 'administrator'가 실패한 경우
ssh administrator@host  # 'Administrator'가 실패한 경우

오류: "Bad key types '+ssh-dss'"

원인: SSH 구성이 제거된 DSA 알고리즘을 참조합니다.

수정:

# 문제 있는 줄 찾기 및 편집
grep -n "ssh-dss" ~/.ssh/config

# 알고리즘 참조 제거 또는 교체
# 수정 전: HostKeyAlgorithms +ssh-dss
# 수정 후:  (전체 줄 제거 또는 최신 알고리즘으로 교체)

오류: "Bad key types '+ssh-rsa,ssh-dss'"

원인: SSH 구성에 DSA를 포함하는 복합 알고리즘 목록이 있습니다.

수정:

# 수정 전
HostKeyAlgorithms +ssh-rsa,ssh-dss
PubkeyAcceptedAlgorithms +ssh-rsa,ssh-dss

# 수정 후(ssh-dss 제거, 레거시 RSA에 필요한 경우 ssh-rsa 유지)
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa

참고: ssh-rsa(SHA-1 서명 포함)도 사용 중단되었습니다. RSA를 사용해야 하는 경우 rsa-sha2-256 또는 rsa-sha2-512를 사용하세요:

HostKeyAlgorithms rsa-sha2-512,rsa-sha2-256
PubkeyAcceptedAlgorithms rsa-sha2-512,rsa-sha2-256

오류: "No matching host key type found"

원인: 원격 서버가 DSA 호스트 키만 제공합니다.

수정: 이는 서버 측에서 조치가 필요합니다. 서버에서 새 호스트 키를 생성합니다:

# 원격 서버에서(콘솔 접근이 있는 경우)
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
sudo systemctl restart sshd

서버를 업데이트할 수 없는 경우 위에 설명된 점프 호스트 또는 Docker 해결 방법을 사용하세요.

오류: "WARNING: connection is not using a post-quantum key exchange algorithm"

원인: 원격 서버가 포스트 양자 키 교환을 지원하지 않습니다.

수정:

# 특정 호스트에 대해 억제
# ~/.ssh/config에 추가:
Host old-server
    WarnWeakCrypto no

# 또는 전역으로 억제(권장하지 않음)
Host *
    WarnWeakCrypto no

오류: "Permission denied (publickey)"

원인: 키 마이그레이션 후 새 키가 서버에서 승인되지 않았습니다.

수정:

# 어떤 키가 제공되고 있는지 확인
ssh -v user@host 2>&1 | grep "Offering public key"

# 올바른 키 배포
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

오류: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"

원인: known_hosts에서 DSA 호스트 키 항목을 제거한 후 서버가 다른 호스트 키 유형을 제공합니다.

수정:

# 이전 호스트 키 항목 제거
ssh-keygen -R hostname

# 재연결하고 새 호스트 키 수락
ssh user@hostname
# 새 호스트 키 지문을 확인하라는 메시지가 표시됩니다

더 넓은 맥락 이해하기

macOS Tahoe 26.3의 SSH 변경은 업계 전반의 더 큰 추세의 일부입니다. 이 맥락을 이해하면 각 변경에 반응하는 것이 아니라 미래의 변경에 대비할 수 있습니다.

OpenSSH 릴리스 타임라인

버전	날짜	주요 변경 사항
7.0	2015	DSA 기본 비활성화
8.2	2020	RSA의 SHA-1 서명 사용 중단
8.8	2022	RSA의 SHA-1 서명 기본 비활성화
9.0	2022	포스트 양자 KEx(sntrup761) 기본 활성화
9.9	2024	ML-KEM 포스트 양자 지원 추가
10.0	2025	DSA 완전 제거, ML-KEM 기본값

macOS는 역사적으로 이러한 릴리스보다 6-12개월 늦게 따라왔으며, DSA 제거가 2025년 4월에 OpenSSH 10.0에 있었음에도 불구하고 2026년 초에 macOS 사용자에게 영향을 미치는 이유가 바로 이것입니다.

다음으로 예상되는 것

OpenSSH 개발 로드맵을 기반으로:

SHA-1 RSA 서명(ssh-rsa)은 OpenSSH 11.x에서 완전히 제거될 가능성이 높습니다
NIST 곡선을 사용하는 ECDSA는 Ed25519를 위해 사용 중단될 수 있습니다
포스트 양자 서명(키 교환만이 아니라)이 추가될 것입니다
인증서 기반 인증이 원시 공개 키보다 점점 더 많이 권장될 것입니다

지금 준비합니다:

모든 키가 Ed25519인지 확인
RSA를 사용해야 하는 경우 rsa-sha2-256/512로 이동
서버에서 포스트 양자 키 교환 테스트
조직의 SSH 인증서 인프라 평가

macOS Tahoe 26.3 업데이트에서 변경된 내용에 대한 자세한 내용은 macOS Tahoe 26.3 릴리스 가이드를 참조하세요.

빠른 참조: 필요한 명령어

이 가이드에서 언급된 모든 명령어의 통합 참조를 작업별로 정리했습니다:

진단

# SSH 버전 확인
ssh -V

# 상세 연결 테스트
ssh -vvv user@host

# 어떤 SSH 바이너리가 실행 중인지 확인
which ssh

# 구성 파일 없이 테스트
ssh -F /dev/null user@host

# 현재 키 유형 확인
for key in ~/.ssh/*.pub; do
    echo "=== $key ==="
    ssh-keygen -l -f "$key"
done

키 생성

# Ed25519 키 생성(권장)
ssh-keygen -t ed25519 -C "description-YYYY" -f ~/.ssh/id_ed25519

# RSA 키 생성(대상이 Ed25519를 지원하지 않는 경우)
ssh-keygen -t rsa -b 4096 -C "description-YYYY" -f ~/.ssh/id_rsa

키 배포

# 원격 서버에 키 배포
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

# macOS 키체인에 키 추가
ssh-add --apple-use-keychain ~/.ssh/id_ed25519

구성 감사

# 구성에서 DSA 참조 찾기
grep -n "ssh-dss" ~/.ssh/config /etc/ssh/ssh_config

# 모든 User 지시어 찾기
grep -n "User " ~/.ssh/config

# 구성 구문 확인
ssh -G test-host

# 권한 수정
chmod 700 ~/.ssh
chmod 600 ~/.ssh/config
chmod 400 ~/.ssh/id_*
chmod 644 ~/.ssh/*.pub

정리

# 이전 호스트 키 제거
ssh-keygen -R hostname

# known_hosts에서 모든 DSA 항목 제거
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.bak
grep -v "ssh-dss" ~/.ssh/known_hosts > ~/.ssh/known_hosts.tmp
mv ~/.ssh/known_hosts.tmp ~/.ssh/known_hosts

자주 묻는 질문

macOS Tahoe 26.3에서 OpenSSH를 다운그레이드하여 DSA 지원을 복원할 수 있나요?

시스템 무결성 보호(SIP)로 인해 macOS에서 시스템 OpenSSH 바이너리를 교체할 수 없습니다. 그러나 Homebrew를 통해 이전 버전을 설치하거나 사용자 정의 위치에서 소스를 컴파일할 수 있습니다. /usr/bin/ssh의 시스템 ssh는 항상 Tahoe 26.3과 함께 제공된 OpenSSH 10.0 버전이 됩니다. 소스에서 OpenSSH 9.7p1을 빌드하는 방법에 대한 자세한 내용은 "레거시 인프라를 위한 해결 방법" 섹션을 참조하세요.

사용자 이름 대소문자 구분 변경은 영구적인가요, 아니면 버그인가요?

OpenSSH 10.0 릴리스 노트와 프로젝트 방향을 기반으로, 이것은 사용자 이름을 대소문자를 구분하는 것으로 정의하는 SSH 프로토콜 사양(RFC 4252)에 부합하는 의도적인 동작으로 보입니다. Apple은 이것이 버그인지 논평하지 않았으며, 되돌아갈 것이라는 징후도 없습니다. 이것을 영구적인 동작으로 취급하고 구성을 적절히 업데이트해야 합니다.

RSA 키도 작동을 멈추나요?

SHA-2 서명(rsa-sha2-256 및 rsa-sha2-512)을 사용하는 RSA 키는 계속 작동하며 예상 가능한 미래에도 지원됩니다. 그러나 SHA-1 서명(ssh-rsa)을 사용하는 RSA 키는 OpenSSH 8.8부터 기본으로 비활성화되었으며 향후 버전에서 완전히 제거될 가능성이 높습니다. RSA 키를 사용하는 경우 최소 3072비트인지, 서버가 SHA-2 서명을 수락하는지 확인하세요. 새 키의 경우 Ed25519가 선호되는 선택입니다.

macOS에서 Windows Server로의 SSH 연결을 어떻게 수정하나요?

Windows Server의 OpenSSH 구현은 역사적으로 사용자 이름에 대해 대소문자를 구분하지 않았습니다. macOS Tahoe 26.3 업데이트 후에는 Windows가 인식하는 정확한 대소문자를 사용해야 합니다. 도메인 계정의 경우 DOMAIN\Username 또는 [email protected]을 사용하세요. 로컬 계정의 경우 컴퓨터 관리에서 계정 이름을 확인하세요. ~/.ssh/config를 적절히 업데이트합니다:

Host windows-server
    HostName win.example.com
    User DOMAIN\\AdminUser
    IdentityFile ~/.ssh/id_ed25519

SFTP 및 SCP에도 영향을 미치나요?

네. sftp와 scp는 모두 동일한 SSH 클라이언트 라이브러리를 사용하며 동일한 대소문자 구분 강제 및 DSA 제거의 적용을 받습니다. 시스템 SSH 바이너리를 사용하는 SFTP 클라이언트(Cyberduck, Transmit 또는 FileZilla 등)도 영향을 받습니다. 자체 SSH 라이브러리를 번들하는 GUI SFTP 클라이언트(자체 libssh2 빌드를 사용하는 Cyberduck 등)는 영향을 받지 않을 수 있지만, 이는 특정 애플리케이션에 따라 다릅니다.

결론

macOS Tahoe 26.3은 적절한 경고 없이 확립된 워크플로우를 중단시키는 SSH 변경 사항을 배포했습니다. 대소문자를 구분하는 사용자 이름 강제, DSA의 완전한 제거, 포스트 양자 키 교환 경고는 각각 주의가 필요하지만, 무엇이 변경되었는지 이해하면 모두 간단하게 해결할 수 있습니다.

즉각적인 조치 항목은 다음과 같습니다:

~/.ssh/config 감사 - User 지시어의 대소문자 불일치를 확인하고 ssh-dss 참조 제거
Ed25519 키 생성 - 남은 DSA 키를 교체하기 위해
새 키 배포 - 인벤토리의 모든 서버에
자동화 스크립트 및 CI/CD 파이프라인 업데이트 - 올바른 사용자 이름 대소문자 및 키 경로로
보안 태세에 따라 포스트 양자 경고 음소거 또는 해결

이러한 변경은 혼란스럽지만 macOS SSH 생태계를 더 강력한 보안 기본값으로 이끌고 있습니다. Ed25519는 DSA보다 빠르고 안전하며 더 작은 키를 생성합니다. 대소문자를 구분하는 사용자 이름은 SSH 프로토콜 사양에 부합합니다. 포스트 양자 키 교환은 미래의 위협으로부터 보호합니다. 마이그레이션의 고통은 현실적이지만 보안 개선은 실질적입니다.

macOS Tahoe에서 새 개발 환경을 설정하는 경우 macOS Tahoe 개발자 설정 가이드로 시작하여 처음부터 올바르게 구성하세요. 더 광범위한 보안 구성에 대해서는 macOS Tahoe 보안 개인 정보 보호 가이드에서 SSH를 넘어선 전체 보안 스택을 다룹니다.

macOS Tahoe 26.3로 SSH가 중단됨: 대소문자 구분 변경, DSA 키 지원 중단 및 완전 수정 가이드

핵심 요점

목차

macOS Tahoe 26.3 SSH에서 정확히 무엇이 변경되었나

변경 사항 1: 대소문자를 구분하는 사용자 이름 매칭

변경 사항 2: DSA(ssh-dss)의 완전한 제거

변경 사항 3: 포스트 양자 키 교환 경고

변경되지 않은 것

업데이트 후 SSH 연결 실패 진단

1단계: 상세 SSH 출력 활성화

2단계: SSH 클라이언트 버전 확인

3단계: 명시적 매개변수로 테스트

4단계: 오류에 대한 SSH 구성 검토

대소문자 구분 변경 이해하기

이 변경이 연결을 중단시키는 이유

중단되는 일반적인 시나리오

DSA 키 제거 이해하기

DSA에 반대하는 보안 논거

"제거됨"이 실제로 의미하는 것

DSA 키가 있는지 확인

포스트 양자 키 교환 경고

경고의 의미

이 경고가 표시되는 경우

경고 음소거

단계별 수정: 대소문자 구분 문제

수정 1: 올바른 사용자 이름 대소문자 확인

수정 2: SSH 구성 파일 업데이트

수정 3: 셸 별칭 및 스크립트 업데이트

수정 4: 환경 변수 업데이트

수정 5: 수정 확인

단계별 수정: DSA에서 Ed25519로 마이그레이션

1단계: DSA 키 인벤토리

2단계: 새 Ed25519 키 생성

3단계: 서버에 새 키 배포

4단계: SSH 구성 업데이트

5단계: 알려진 호스트 정리

6단계: 모든 것이 작동하는지 확인

7단계: DSA 키 폐기

완전한 SSH 구성 감사 가이드

감사 1단계: 사용 중단된 알고리즘 확인

감사 2단계: 구성 구문 확인

감사 3단계: 모든 User 지시어 검토

감사 4단계: 파일 권한 확인

감사 5단계: 권장되는 최신 SSH 구성 템플릿

SSH 에이전트 변경 및 키체인 통합

키체인 통합

영구적인 키 로딩

SSH 에이전트 확인

CI/CD 파이프라인 및 자동화에 미치는 영향

GitHub Actions

GitLab CI

Jenkins

Ansible Playbooks

자동화된 백업 스크립트

원격 개발 워크플로우에 미치는 영향

VS Code 원격 SSH

JetBrains Gateway / 원격 개발

tmux 및 영구 세션

레거시 인프라를 위한 해결 방법

해결 방법 1: 점프 호스트 사용(권장)

해결 방법 2: Docker 컨테이너 사용

해결 방법 3: Homebrew를 통해 이전 OpenSSH 설치

해결 방법 4: Linux 가상 머신 사용

장기적: 장치 교체 계획

2026년 SSH 보안 모범 사례

키 관리 모범 사례

서버 측 강화

모니터링 및 경고

일반적인 오류 해결

오류: "Connection closed by X.X.X.X port 22"

오류: "Bad key types '+ssh-dss'"

오류: "Bad key types '+ssh-rsa,ssh-dss'"

오류: "No matching host key type found"

오류: "WARNING: connection is not using a post-quantum key exchange algorithm"

오류: "Permission denied (publickey)"

오류: "WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED"

더 넓은 맥락 이해하기

OpenSSH 릴리스 타임라인

다음으로 예상되는 것

빠른 참조: 필요한 명령어