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 validatorinit이 생성하는 서명자 키. 스테이킹 소유자의 키는 절대 요구하지 않습니다해당 호스트용으로 암호화된 같은 키. 관찰만 하는 동안 노드는 별도의 identity로 실행됩니다
BNB Chain validator서명 자료와 피어 identity의 백업암호화된 키스토어 안의 컨센서스 키, 암호화된 지갑 안의 투표 키, 해당 호스트용으로 암호화된 그 비밀번호들
Kaia validator(컨센서스 노드 또는 프록시 노드)노드 identity의 백업호스트에서 만들어 해당 호스트용으로 암호화된 노드 identity. 운영자의 지갑은 erpc 밖에 둡니다
Monad 노드(RPC 또는 validator)원본 키스토어 두 개 모두해당 호스트용으로 암호화된 같은 키스토어
Hyperliquid validator핫 컨센서스 키. 콜드 계정의 키는 절대 요구하지 않습니다해당 호스트용으로 암호화되며, 활성화된 validator 유닛만 불러오는 핫 키
Hyperliquid AQA 퍼블리셔전용 API key 또는 에이전트 키해당 호스트용으로 암호화된 같은 키
NEAR validator컨센서스 키해당 호스트용으로 암호화된 같은 키
Arbitrum validatorinit이 생성하는 지갑과 프로바이더 자격 증명암호화된 프로바이더 자격 증명, 그리고 --activate-signer 이후에는 root 소유로 암호화된 지갑도 있습니다
Robinhood Chain validatorinit이 생성하는 지갑과 프로바이더 설정암호화된 프로바이더 설정, 그리고 --activate-signer 이후에는 root 소유로 암호화된 지갑도 있습니다
OP 계열 RPC인벤토리와 프로바이더 값암호화된 프로바이더 자격 증명, 엔진 JWT, 피어 identity. 소유자 기록과 호스트의 암호화 시크릿을 백업하세요
Nitro RPC인벤토리와 업스트림 자격 증명암호화된 업스트림 자격 증명
그 밖의 RPC 노드는 validator용 서명 키를 보유하지 않지만, 그 호스트에는 엔진 JWT, 피어 identity, RPC 쿠키처럼 클라이언트가 스스로 만드는 것이 남습니다.
키 백업만으로는 validator 복구가 안전해지지 않습니다. 서버를 교체하거나 데이터를 복원하기 전에 체인의 복구 절차를 따르세요. 각 체인의 가이드에서 키를 복원하는 방법을 설명합니다(노드).
사용자의 머신에서 노드 키를 디스크에 쓰는 명령은 하나뿐입니다. erpc validator vote-account는 Solana CLI가 실행되는 동안 identity 키와 투표 키를 상태 디렉터리 아래의 0600 파일에 쓰고, 실행이 끝나면 지웁니다. 프로세스가 비정상 종료되면 이후 실행에서 정리될 때까지 파일이 남을 수 있습니다.
erpc worker 앱의 트레이딩 키와 시크릿은 이것들과 별도로 보관됩니다. 키 및 시크릿을 참고하세요.

erpc가 유지하는 파일

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