---
title: "SSH에서 Alpacon으로 전환"
description: "기존 SSH 접근을 Alpacon 작업 세션으로 단계적으로 전환합니다. 현재 사용자와 키를 조사하고 두 경로를 함께 운영하면서 접속, 자동화, 파일 전송을 검증하세요. SSH 포트를 닫기 전에는 비상 접속 경로를 남기고, 문제가 생겼을 때 되돌리는 절차를 꼭 준비합니다."
---

> Full documentation index: https://docs.alpacax.com/llms.ko.txt

# SSH에서 Alpacon으로 전환

<span id="ssh에서-마이그레이션" />
# SSH에서 Alpacon으로 전환

기존 SSH 키 관리에서 Alpacon의 제로 트러스트 아키텍처로 옮기면 보안이 한층 탄탄해지고, 감사 추적이 쉬워지며, 접근 관리도 단순해집니다. 이 가이드는 그 전환 과정을 단계별로 안내합니다.

<span id="왜-ssh에서-마이그레이션해야-할까요" />

## SSH에서 전환하는 이유

### SSH 키 관리의 문제점

기존 SSH를 운영하다 보면 다음과 같은 문제에 부딪힙니다:

- **키 확산**: SSH 키가 중앙 추적 없이 서버 전체에 확산됨
- **만료 없음**: 수동으로 교체하지 않는 한 키가 무기한 유효함
- **제한된 감사 추적**: 누가 언제 무엇에 접근했는지 추적하기 어려움
- **복잡한 키 교체**: 수동 프로세스로 인해 오류와 서비스 중단 발생
- **공유 계정**: 여러 사용자가 동일한 SSH 사용자 계정을 공유
- **키 분실**: 장치가 손상된 경우 원격으로 접근을 취소할 방법이 없음

### Alpacon의 장점

Alpacon은 이런 문제들을 다음과 같이 해결합니다:

- **중앙 집중식 접근 제어**: 단일 대시보드에서 모든 접근 관리
- **시간 제한 접근**: 작업 세션과 토큰이 자동으로 만료됨
- **완전한 감사 로그**: 모든 명령과 작업이 기록됨
- **즉시 취소**: 웹 콘솔에서 즉시 접근 제거
- **개별 책임성**: 각 사용자가 자신의 고유한 신원을 가짐
- **노출된 포트 없음**: 서버가 인터넷에 SSH 포트를 열 필요 없음

## 마이그레이션 전략

### 1단계: 병렬 운영 (권장)

처음에는 Alpacon과 SSH를 함께 운영하면 위험 없이 매끄럽게 전환할 수 있습니다.

```mermaid
graph LR
    A[현재 상태] --> B[Alpacon 에이전트 설치]
    B --> C[접근 테스트]
    C --> D[사용자 마이그레이션]
    D --> E[SSH 비활성화]
    E --> F[마이그레이션 완료]
```

1. **Alpacon 에이전트 설치** - SSH를 활성화한 상태에서 서버에 설치
2. **연결 테스트** - Alpacon 웹 콘솔을 통해 테스트
3. **접근 권한 부여** - Alpacon을 통해 팀원에게 접근 권한 부여
4. **사용량 모니터링** - 모든 워크플로가 지원되는지 확인
5. **SSH 키 사용 점진적 감소**
6. **SSH 비활성화** - Alpacon에 대한 확신이 생기면 비활성화

### 2단계: 사용자 마이그레이션

#### 기존 접근 인벤토리

먼저 현재 SSH 접근 현황부터 점검합니다:

```bash
# 서버의 모든 authorized keys 나열
find /home -name "authorized_keys" -exec ls -la {} \;

# SSH 구성 확인
cat /etc/ssh/sshd_config | grep -E "^(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)"

# sudo 권한 검토
cat /etc/sudoers
getent group sudo
```

#### Alpacon 역할에 사용자 매핑

| SSH 접근 패턴 | Alpacon 구성 |
|----------------|-------------|
| 키를 통한 root 접근 | 웹 터미널과 권한 상승 범위의 작업 세션. root 직접 로그인은 `allow_direct_root`와 MFA 필요 |
| sudo 사용자 | 작업 세션으로 접근하고, 권한 상승은 sudo with MFA 정책으로 처리 |
| 애플리케이션 사용자 | 특정 명령(명령 ACL)으로 범위가 제한된 서비스 토큰을 가진 Application |
| 읽기 전용 접근 | 읽기 전용 범위의 RBAC 역할 |
| 서비스 계정 | 자동화를 위한 서비스 토큰을 가진 Application |

Superuser와 Staff는 워크스페이스 관리 역할이며, 그 자체로 서버 셸 접근을 부여하지 않습니다. 평소에 사람은 요청·승인·시간 제한을 거치는 [작업 세션](/use/work-sessions/)으로 서버에 접근하고, 자동화는 3단계에서 보듯 범위 제한 토큰을 사용합니다.

### 3단계: 워크플로 마이그레이션

#### 대화형 세션

**이전 (SSH):**
```bash
ssh user@server.example.com
```

**이후 (Alpacon):**
```bash
alpacon websh production-server
# 또는 Alpacon 워크스페이스의 웹 콘솔 사용
```

#### 파일 전송

**이전 (SCP/SFTP):**
```bash
scp file.txt user@server:/path/to/destination
```

**이후 (Alpacon WebFTP):**
- Alpacon 콘솔에서 WebFTP 인터페이스 사용
- 브라우저에서 직접 파일을 드래그 앤 드롭
- 또는 CLI 사용: `alpacon cp file.txt production-server:/path/to/destination`

#### 자동화 및 CI/CD

**이전 (GitHub Actions에서 SSH):**
```yaml
- name: Deploy via SSH
  uses: appleboy/ssh-action@v1
  with:
    host: ${{ secrets.HOST }}
    username: ${{ secrets.USERNAME }}
    key: ${{ secrets.SSH_KEY }}
    script: |
      cd /app
      git pull
      npm install
      pm2 restart app
```

**이후 (GitHub Actions에서 Alpacon):**
```yaml
- name: Deploy via Alpacon
  uses: alpacax/alpacon-websh-action@v1
  with:
    workspace-url: ${{ secrets.ALPACON_WORKSPACE_URL }}
    api-token: ${{ secrets.ALPACON_SERVICE_TOKEN }}
    target: 'production-server'
    script: |
      cd /app
      git pull
      npm install
      pm2 restart app
```

#### 서드파티 도구 API 통합

Alpacon을 기본 지원하지 않는 도구라면 REST API를 사용하세요:

```bash
# REST API를 통해 명령 실행
curl -X POST https://your-workspace.ap1.alpacon.io/api/events/commands/ \
  -H "Authorization: token=\"alpst-xxxxxxxxxxxxxxxxxx\"" \
  -H "Content-Type: application/json" \
  -d '{
    "server": "7e3984de-49ab-4cc6-bcdf-21fbd35858b8",
    "line": "systemctl restart nginx",
    "username": "ubuntu"
  }'
```

전체 문서는 [API 레퍼런스](/reference/api/commands/)를 참조하세요.

## 마이그레이션 체크리스트

마이그레이션 진행 상황을 추적하려면 이 체크리스트를 사용하세요:

### 준비 단계
- [ ] 모든 SSH 키와 구성 백업
- [ ] 현재 사용자와 권한 문서화
- [ ] Alpacon 워크스페이스 받기
- [ ] 마이그레이션 일정 계획
- [ ] 중요한 워크플로 식별

### 구현 단계
- [ ] 모든 대상 서버에 Alpamon 설치
- [ ] 워크스페이스에 서버 등록
- [ ] 사용자 그룹 및 역할 구성
- [ ] CI/CD 파이프라인 업데이트
- [ ] 모니터링 및 알림 설정
- [ ] 모든 팀원의 접근 테스트

### 검증 단계
- [ ] 모든 사용자가 서버에 접근할 수 있는지 확인
- [ ] 모든 CI/CD 파이프라인 테스트
- [ ] 감사 로그 검토
- [ ] 성능 메트릭 검증
- [ ] 문제 또는 해결 방법 문서화

### 완료 단계
- [ ] SSH 포트 비활성화
- [ ] SSH 키 제거
- [ ] 문서 업데이트
- [ ] 팀 교육 완료
- [ ] 마이그레이션 후 검토 일정 잡기

## 보안 고려사항

### SSH 비활성화 전

SSH 접근을 비활성화하기 전에 다음 항목이 완료되었는지 확인하세요:

- [ ] 모든 팀원이 Alpacon 접근을 구성함
- [ ] 긴급 접근 절차가 문서화됨
- [ ] 백업 접근 방법을 사용할 수 있음 (콘솔/IPMI)
- [ ] 모니터링 알림이 Alpacon을 사용하도록 업데이트됨
- [ ] 자동화 스크립트가 서비스 토큰을 사용하도록 마이그레이션됨
- [ ] 제한된 사용자에 대해 명령 ACL이 구성됨

### 마이그레이션 후 강화

Alpacon으로 마이그레이션한 후:

1. **SSH 서비스 비활성화**:
```bash
# SSH 데몬 비활성화
sudo systemctl disable sshd
sudo systemctl stop sshd
```

2. **방화벽 포트 닫기**:
```bash
# 방화벽에서 SSH 포트 제거
sudo ufw delete allow 22/tcp
```

3. **authorized keys 제거**:
```bash
# 오래된 SSH 키 정리
find /home -name "authorized_keys" -exec rm {} \;
find /root -name "authorized_keys" -exec rm {} \;
```

## 롤백 계획

SSH 접근을 다시 활성화해야 하는 경우:

1. **Alpacon 콘솔을 통해**:
```bash
# SSH 서비스 재활성화
sudo systemctl enable sshd
sudo systemctl start sshd

# 방화벽 포트 열기
sudo ufw allow 22/tcp

# 긴급 SSH 키 추가
echo "ssh-rsa YOUR_EMERGENCY_KEY" >> ~/.ssh/authorized_keys
```

2. **물리적/콘솔 접근을 통해**:
- 클라우드 제공업체의 콘솔 접근 사용 (AWS Systems Manager, GCP Serial Console)
- 사용 가능한 경우 IPMI/iDRAC를 통해 서버에 접근
- 온프레미스 서버에 대한 물리적 접근

## 일반적인 마이그레이션 시나리오

### 개발 서버

개발 서버에서 먼저 전환 절차를 시험할 수 있습니다:

1. Alpacon 에이전트 설치
2. 모든 개발 워크플로 테스트
3. 팀 피드백 수집
4. 학습한 내용을 프로덕션 마이그레이션에 적용

### 프로덕션 서버

신중하게 계획해야 합니다:

1. 유지보수 기간 예약
2. 모든 이해 관계자에게 알림
3. 먼저 스테이징 환경에서 테스트
4. 롤백 계획 준비
5. 마이그레이션 후 면밀히 모니터링

### 레거시 시스템

즉시 마이그레이션할 수 없는 시스템:

1. 별도의 네트워크 세그먼트에서 레거시 서버 격리
2. 단일 진입점으로 Alpacon 점프 서버 사용
3. 점진적으로 현대화 및 마이그레이션
4. 규정 준수를 위한 엄격한 감사 로그 유지

## 마이그레이션 문제 해결

### "마이그레이션 후 연결할 수 없음"

확인 사항:
- Alpacon 에이전트가 실행 중인지: `systemctl status alpamon`
- 서버가 워크스페이스에 등록되었는지
- 사용자에게 적절한 권한이 있는지
- 방화벽이 아웃바운드 HTTPS(포트 443)를 허용하는지

### "자동화 스크립트 실패"

확인 사항:
- 서비스 토큰이 활성 상태이고 필요한 접근 범위를 갖췄는지
- 명령 ACL이 필요한 명령을 허용하는지
- 환경 변수가 올바르게 설정되었는지
- 스크립트 경로가 상대 경로가 아닌 절대 경로인지

### "파일 전송이 작동하지 않음"

확인 사항:
- 워크스페이스에 WebFTP가 활성화되어 있는지
- 사용자에게 파일 전송 권한이 있는지
- 대상 디렉터리에 적절한 권한이 있는지
- 사용 가능한 디스크 공간이 충분한지

## 다음 단계

- [보안 모범 사례](/learn/best-practices/security/) 검토
- [모니터링 및 알림](/learn/best-practices/monitoring/) 설정
- [명령 ACL](/learn/key-concepts/zero-trust/) 구성
- [모니터링](/use/audit/) 설정

## 도움이 필요하신가요?

- 마이그레이션 지원을 위해 [Discord 커뮤니티](https://discord.gg/wadWh8VsYB)에 가입하세요
- 이메일: support@alpacax.com
- 문서: [문제 해결 가이드](/use/work-sessions/troubleshoot-connections/)

Source: https://docs.alpacax.com/ko/use/servers/migrate-from-ssh/