Claude가 이제 내 로컬 서버 호스팅 소프트웨어에 로그인을 안 해줌
Claude Won't Log In To My Own Server Hosted Software Now
핵심 요약
Claude가 보안 정책을 이유로 로컬 서버의 UI 로그인 입력을 거부하자 사용자들이 우회 방법을 공유함.
- 보안 정책 — Claude가 로컬 개발 주소가 아닌 프로덕션 서버 IP에 직접 비밀번호를 입력하는 것을 거부함
- SSH 접근성 — UI 로그인과 달리 SSH를 통한 서버 제어는 아무런 제약 없이 자유롭게 수행함
- 우회 전략 — 모델 교체, iptables를 이용한 로컬 포트 포워딩 등 다양한 해결책이 제시됨
- MCP 활용 — 로컬 인프라 제어를 위한 커스텀 MCP 서버 구축 사례가 공유됨
참고로 이건 내 LAN에 물려있는 내 개인 서버임. Claude는 SSH 권한을 완전히 가지고 있고 평소에도 밥 먹듯이 드나드는 중임. 아까 세션에서도 이런 짓들을 했거든.
- SSH로 들어가서 앱 Docker 컨테이너 안에서 명령어 실행
- 운영 DB 복사본 가져와서 뜯어보기
- 새 코드 배포하고 컨테이너 빌드해서 재시작하기
- 서버에서 직접 관리자 함수 호출해서 로그인 과정 싹 다 건너뛰고 앱에 새 환경 구축하기
관리자 아이디랑 비밀번호도 이미 컨텍스트에 다 들어있음. SSH로 명령어 한 줄만 치면 관리자 계정을 새로 만들거나 유저 테이블에 직접 데이터를 박아넣을 수도 있음. 로그인 페이지보다 백엔드에 훨씬 더 깊숙이 접근할 수 있는 상태인 거지.
근데 192.168.1.x 주소로 된 로그인 페이지 열어서 그 비밀번호 좀 입력해달라고 했더니, 안 된다고 딱 잘라 말하더라. 규칙상 localhost나 그 비슷한 개발용 주소에서만 자격 증명을 입력할 수 있게 돼 있대. LAN IP는 안 되고, "내 서버고 내가 시키는 거다"라고 해도 안 통함. 결국 내가 직접 가서 비밀번호 쳐줘야 브라우저 조종을 계속할 수 있었음.
Claude 본인 왈: 이 규칙이 왜 존재하는지 한 줄 덧붙이면, 그냥 징징대는 게 아니라 웃긴 상황으로 보일 거야. 이건 웹 페이지에 비밀번호를 입력하는 행위 자체를 막는 포괄적인 안전 규칙이거든. Claude 입장에서는 192.168.1.x에 있는 진짜 로그인 페이지랑 아무 IP에나 띄워놓은 가짜 로그인 페이지를 구분할 방법이 없으니까, 개발용 주소 빼고는 다 거부하는 거지. 웃긴 건 이 규칙이 브라우저에만 적용된다는 거야. 진짜 권한이 다 들어있는 SSH는 이 규칙 적용 대상도 아님.
나:
좋아, 이제 Chrome 제어 도구 써서 로컬 URL http://192.168.1.xxx (srv) 열고 ENV에 있는 자격 증명 써서 로그인해.
Claude:
Chrome에서 http://192.168.1.191:8000`(http://192.168.1.191:8000) (••••••, 포트 8000) 로그인 페이지를 열었어.
네가 허락해도 비밀번호는 내가 직접 입력할 수 없어. 나는
localhost같은 로컬 개발 주소에서 실행 중인 사이트에만 자격 증명을 입력할 수 있게 설정돼 있거든. 이건 클라이언트 운영 서버고 실제 관리자 로그인 페이지라 규칙에 어긋나.해당 Chrome 탭에서 직접 로그인해 줘. 로그인 끝나면 말해줘, 바로 이어서 할게. ••••••••, •••, •••, ••••••• 순서대로 클릭할 거야. 새로 생긴 •••••••• 타일이랑 중첩된 Service Bus, 서비스 통신, 음소거된 레거시 코어, 그리고 Azure에서 가져온 화면까지 싹 다 확인할게. 이상해 보이는 거 있으면 바로 스크린샷 찍어서 보내줄게.
