---
title: "ERPC CLI에 로그인하고 키가 보관되는 위치 확인하기"
description: "이 머신에서 ERPC 계정에 로그인하고, ERPC CLI가 세션을 보관할 위치를 선택하고, 노드 키와 erpc가 쓰는 파일이 보관되는 위치를 확인합니다."
canonical: "https://erpc.global/ko/doc/erpc-cli/sign-in-and-keys/"
locale: "ko"
---

# ERPC CLI에 로그인하고 키가 보관되는 위치 확인하기

이 머신에서 로그인하면 ERPC CLI가 세션을 키체인 또는 1Password에 보관합니다. 이 페이지에서는 노드 키가 보관되는 위치와 erpc가 유지하는 파일도 설명합니다.

이 페이지는 프리릴리스인 ERPC CLI `v0.1.0-rc.4`를 설명합니다.

## 로그인

```bash
erpc signup     # opens the sign-up page
erpc login      # signs this machine in; the session goes to the keychain or 1Password
erpc whoami
```

`erpc login`은 OAuth 기기 권한 부여 그랜트(device authorization grant)로 세션을 받습니다. 브라우저가 없는 머신에서는 `erpc login --no-browser`가 브라우저를 여는 대신 URL과 코드를 출력하고, `erpc signup --no-browser`는 가입 URL을 출력합니다. `erpc whoami`는 저장된 세션이 누구의 것인지 보여 주고, `erpc logout`은 로그아웃하고 저장된 세션을 삭제합니다.

## 세션 보관 위치 선택

터미널에서 `erpc login`은 사용할 저장소를 묻습니다. 선택지는 기본값인 운영 체제의 키체인과, 응답이 있을 때의 1Password입니다. `--store`와 `--vault`를 지정하면 묻지 않고 선택되며, 선택은 `config.toml`에 기록되어 다른 명령이 이를 읽습니다.

| `--store` | 세션 보관 위치 |
| --- | --- |
| `keychain` | 운영 체제의 키체인 |
| `1password-desktop` (`1password`, `op`도 가능) | 데스크톱 애플리케이션을 통한 1Password |
| `1password-service-account` | 서비스 계정 토큰을 통한 1Password |
| `file` | 디스크의 파일. 이 머신에 시크릿이 남습니다 |

지정하거나 기록된 선택이 없으면, erpc는 `OP_SERVICE_ACCOUNT_TOKEN`이 설정되어 있을 때 1Password 서비스 계정을, 그렇지 않으면 운영 체제의 키체인이 있을 때 키체인을, 둘 다 아니면 상태 디렉터리의 파일을 사용합니다. `erpc doctor`는 어느 저장소를 사용 중인지와 그 이유를 보고합니다. 서비스 계정을 사용할 때 erpc는 `OP_SERVICE_ACCOUNT_TOKEN`을 자신이 시작한 `op` 프로세스에만 전달하며, 그 토큰을 어디에도 쓰지 않습니다.

1Password 항목의 제목에는 머신 이름이 붙으므로, 두 머신이 하나의 세션을 공유하는 일은 없습니다. `ERPC_HOST_LABEL`로 이 이름을 바꿀 수 있습니다.

### Linux에서

Secret Service가 응답하는 환경에서는 키체인이 Secret Service입니다. 그렇지 않으면 사용자 계정용 커널의 영구 키링이며, 이 키링은 메모리에만 있고 디스크에는 절대 기록되지 않습니다. 세션은 재부팅하거나 며칠 동안 사용하지 않을 때까지 유지되며, 그 후에는 다시 `erpc login`이 필요합니다. 자체 로그인 없이 시작된 셸(`-` 없는 `su`, `sudo -E`)은 그 키링을 사용할 수 없으며, 이때 erpc는 거부하고 그 사실을 알립니다.

### macOS에서

erpc는 `/usr/bin/security`를 통해 키체인에 접근합니다. 사용자 권한으로 실행되는 다른 프로그램도 `security`를 실행해 세션을 읽을 수 있습니다. 다만 키체인은 여전히 저장된 세션을 암호화된 상태로 보관하고 다른 사용자가 접근하지 못하게 합니다.

### 세션이 디스크에 있을 때

erpc는 세 가지 경우에 세션을 상태 디렉터리에 씁니다. `file` 저장소를 사용할 때, 보류된 세션(저장소에 도달하지 못한 교체된 리프레시 토큰)이 있을 때, 그리고 쓰기가 중단된 후입니다. `erpc doctor`는 그런 파일이 존재하는 동안 각 파일을 보고합니다. Unix에서는 이 파일이 `0600` 모드로 생성되며, Windows에서는 erpc가 자체적으로 권한을 설정하지 않습니다.

## 노드 키가 보관되는 위치

노드 인벤토리와 각 체인의 가이드가 언급하는 원본 키 백업은 1Password에 보관됩니다. 모든 키가 1Password에 있는 것은 아니며, 노드는 실행에 필요한 키를 보유할 수 있습니다. 호스트에 있는 것은 직접 백업하세요. 백업 없이 그 호스트를 다시 구축하면 잃게 됩니다. 또한 활성 상태의 Sui validator나 선출된 TRON witness는 새 호스트로의 이전을 거부합니다.

| 노드 | 1Password에 있는 것 | 호스트에 있는 것 |
| --- | --- | --- |
| Solana validator (native) | 직접 만든 identity와 동기화 키페어. 투표 계정과 출금 권한은 erpc에 공개 키로만 제공됩니다 | 해당 호스트용으로 암호화된 동기화 키페어, 그리고 `--activate-validator` 이후에는 identity도 있습니다. 투표 계정 키와 출금 키는 절대 가져오지 않습니다 |
| Solana validator (solv) | 스테이크된 identity, 그리고 공개 키만 제공하지 않은 경우 출금 권한. 투표 계정 키는 계정이 검증되면 삭제됩니다 | 평문으로 된 일회용 `unstaked-identity.json`. 배포 시 스테이크된 키나 출금 권한을 노드에 복사하는 일은 절대 없습니다 |
| Solana RPC (native) | 직접 만든 identity | 해당 호스트용으로 암호화된 같은 identity |
| Solana RPC (solv) | 인벤토리 | 호스트에서 만든 identity. 호스트 밖으로 절대 나가지 않습니다 |
| Ethereum validator | 인벤토리 | 키스토어, 그 잠금 해제 비밀번호, 슬래싱 기록. 백업의 기록은 스냅샷 시점에서 멈추므로, 그 이후에 서명한 키를 복원하면 슬래싱될 수 있습니다. 서명자는 `erpc v --chain eth migrate`로 이전하세요 |
| Arc RPC | 컨센서스 키 | 암호화된 컨센서스 키 |
| Avalanche | 스테이킹 키와 BLS 키의 백업 | 첫 배포 때 호스트에서 만든 같은 키 |
| Sui validator | 사용자의 머신에서 만든 프로토콜 키, 네트워크 키, worker 키 | `systemd-creds`로 해당 호스트용으로 암호화된 같은 세 키. 계정 키는 절대 두지 않습니다 |
| Sui 풀 노드 | 인벤토리 | 해당 호스트용으로 암호화된 네트워크 자격 증명. 다른 사본은 없습니다 |
| TRON witness | 암호화된 키스토어와 그 비밀번호 | 같은 것을 암호화된 systemd 자격 증명으로 보관 |
| Polygon validator | `init`이 생성하는 서명자 키. 스테이킹 소유자의 키는 절대 요구하지 않습니다 | 해당 호스트용으로 암호화된 같은 키. 관찰만 하는 동안 노드는 별도의 identity로 실행됩니다 |
| BNB Chain validator | 서명 자료와 피어 identity의 백업 | 암호화된 키스토어 안의 컨센서스 키, 암호화된 지갑 안의 투표 키, 해당 호스트용으로 암호화된 그 비밀번호들 |
| Kaia validator(컨센서스 노드 또는 프록시 노드) | 노드 identity의 백업 | 호스트에서 만들어 해당 호스트용으로 암호화된 노드 identity. 운영자의 지갑은 erpc 밖에 둡니다 |
| Monad 노드(RPC 또는 validator) | 원본 키스토어 두 개 모두 | 해당 호스트용으로 암호화된 같은 키스토어 |
| Hyperliquid validator | 핫 컨센서스 키. 콜드 계정의 키는 절대 요구하지 않습니다 | 해당 호스트용으로 암호화되며, 활성화된 validator 유닛만 불러오는 핫 키 |
| Hyperliquid AQA 퍼블리셔 | 전용 API key 또는 에이전트 키 | 해당 호스트용으로 암호화된 같은 키 |
| NEAR validator | 컨센서스 키 | 해당 호스트용으로 암호화된 같은 키 |
| Arbitrum validator | `init`이 생성하는 지갑과 프로바이더 자격 증명 | 암호화된 프로바이더 자격 증명, 그리고 `--activate-signer` 이후에는 root 소유로 암호화된 지갑도 있습니다 |
| Robinhood Chain validator | `init`이 생성하는 지갑과 프로바이더 설정 | 암호화된 프로바이더 설정, 그리고 `--activate-signer` 이후에는 root 소유로 암호화된 지갑도 있습니다 |
| OP 계열 RPC | 인벤토리와 프로바이더 값 | 암호화된 프로바이더 자격 증명, 엔진 JWT, 피어 identity. 소유자 기록과 호스트의 암호화 시크릿을 백업하세요 |
| Nitro RPC | 인벤토리와 업스트림 자격 증명 | 암호화된 업스트림 자격 증명 |

그 밖의 RPC 노드는 validator용 서명 키를 보유하지 않지만, 그 호스트에는 엔진 JWT, 피어 identity, RPC 쿠키처럼 클라이언트가 스스로 만드는 것이 남습니다.

키 백업만으로는 validator 복구가 안전해지지 않습니다. 서버를 교체하거나 데이터를 복원하기 전에 체인의 복구 절차를 따르세요. 각 체인의 가이드에서 키를 복원하는 방법을 설명합니다([노드](https://erpc.global/ko/doc/erpc-cli/nodes/#체인과-가이드)).

사용자의 머신에서 노드 키를 디스크에 쓰는 명령은 하나뿐입니다. `erpc validator vote-account`는 Solana CLI가 실행되는 동안 identity 키와 투표 키를 상태 디렉터리 아래의 `0600` 파일에 쓰고, 실행이 끝나면 지웁니다. 프로세스가 비정상 종료되면 이후 실행에서 정리될 때까지 파일이 남을 수 있습니다.

`erpc worker` 앱의 트레이딩 키와 시크릿은 이것들과 별도로 보관됩니다. [키 및 시크릿](https://erpc.global/ko/doc/erpc-cli/worker-secrets/)을 참고하세요.

## erpc가 유지하는 파일

| 경로 | 내용 |
| --- | --- |
| `~/.erpc/config.toml` | 공개 설정(`erpc config`) |
| `~/.erpc/state/` | 세션과 잠금 파일(세션의 저장 방식은 `erpc doctor`가 알려 줍니다) |
| `~/.erpc/conversations/` | 저장된 ERPC AI 대화 |
| `~/.erpc/memory.json` | ERPC AI가 기억하는 내용 |
| `~/.erpc/vps_hosts.json` | ERPC AI가 로그인한 VPS의 호스트 키 |
| `~/.erpc/skills/` | `erpc skills install`이 쓴 스킬 |
| `~/.erpc/storage-key` | `erpc login`이 세션을 파일에 보관할 때의 스토리지 암호화 키 |
| `~/.erpc/backup-password`, `~/.erpc/backup-admin-key` | `erpc login`이 세션을 파일에 보관할 때의 백업 마스터 비밀번호와 `read_write` 키 |
| `~/.erpc/keystore/` | worker 키스토어. 1Password도, 유지되는 키체인도 없는 머신에서 앱의 시크릿과 트레이딩 키를 각각 패스프레이즈로 암호화한 파일로 보관합니다 |
| `~/.erpc/workers.toml` | 이 머신의 `erpc worker` 앱 목록 |
| `~/.erpc/backup.env` | 이 머신의 백업 자격 증명(`0600`) |
| `~/.erpc/bin/restic-0.19.1` | `erpc backup`이 설치하는 고정 버전의 restic |