공유 사용자로 로그인하는 것이 나쁜 습관입니까?

35

나는 기계에 로그인하고 싶은 사람마다 새로운 우분투 사용자를 생성하는 대신 sysadmins가 각 사용자의 ssh 키를 단순히에 추가 .ssh/authorized_keys하고 모든 사람 ssh은 ( 예 ) ubuntu@host또는 로 기계에 추가하는 조직에서 일했습니다 ec2-user@host. (실수로, 랩 환경에서 공유 Mac mini에서도이 기능을 사용하는 것을 보았습니다.)이 방법이 허용됩니까?

문제의 호스트는 주로 테스트에 사용되지만 일반적으로 사용자 별 구성이 필요하고 현재 일반 git을 사용하여 수행되는 git commit 생성 및 푸시와 같은 특정 사용자가 수행 한 것으로 추적되는 작업도 있습니다. 사용자.

ssh user-management

— 사용자 22a6db72d7249
소스

23

많은 사람들이 폴리 사랑의 관계에 문제가 있지만, 다른 사람은 나는 그것이 반드시 공유 할 수있는 "나쁜 습관"생각하지 않도록 ... 아, 신경 끄시 고, 사용자의 의미, 잘 그들을 처리 계정을 .

— HopelessN00b

Awww, 누군가가 clickbait 제목을 편집했습니다 .. :(

— Burgi

42

예, 나쁜 습관입니다. 그것은 악의적 인 사람이 아무도 없을 것이라고 가정하고 아무도 실수하지 않는다는 기본 가정에 의존합니다. 공유 계정이 있으면 책임이없고 제한없이 일이 발생하는 것이 사소한 일입니다. 사용자가 무언가를 깨 뜨리면 모든 사람이이를 깨뜨립니다.

이 uid 공유 체계의 이유가 단순히 새로운 계정을 만들고 구성을 공유하는 데 드는 관리 비용을 줄이는 것이라면 관리자는 Ansible , Chef , Puppet 또는 Salt 같은 자동화 시스템에 시간을 투자 하여 사용자를 만드는 것과 같은 일을해야합니다. 여러 컴퓨터의 계정이 매우 간단합니다.

— thkala
소스

4

악의도 아니며, 무능하지도 않습니다. 때 아무것도 내가하지 작업을 수행, 나는이 계정에서 수행 된 기억 아무것도 것이라고 가정 할 수 없다.

— djechlin

보안 데이터의 원칙 : 무결성 기밀 가용성 책임. 책임이라는 단어를 사용하여 +1

— DeveloperWeeks

7

이것으로 시작해도 충격을받지 않으며 매우 안전한 환경에서 일합니다. 모든 사람은 자신의 사용자와 컴퓨터 및 ssh 키를 가지고 있으며 필요한 경우 로깅 릴레이를 통해 루트 또는 다른 사용자로 ssh 서버로 작업합니다. 우리가하는 모든 일은 ssh 키의 소유자가 수행 한 것으로 기록되므로 책임은 괜찮습니다.

대안은 무엇입니까? 루트는 말할 것도없고 특정 사용자로해야 할 일이 많습니다. Sudo? 매우 제한된 특정 작업에는 문제가 없지만 시스템 관리에는 적합하지 않습니다.

그러나 마지막 단락에 대해 잘 모르겠습니다. 누군가 일반 사용자에게 자식 커밋을 푸시 할 수 있음을 의미합니까? 그것은 책임을 어길 것이며, 책임을 어기는 것은 나쁘다. 우리는 로그인 한 컴퓨터에서 자식을하고 ssh 키로 자식을 인증합니다 ...

인증, 권한 부여 및 계정 (AAA)은 고전적인 표현입니다. ssh 키로 인증되고 키가 authorized_keys에 있으므로 일반 사용자가 수행 할 수있는 모든 작업을 수행 할 수있는 권한이 있으며 사용자가 수행하는 작업을 수행하려면 계정이 필요합니다 사실 후에 검토 할 수 있습니다.

— 법 29
소스

3

따라서 일반 사용자에게는 git repo?를 수정할 권한이있는 일종의 인증 (ssh 키?)이 있습니까? 정말 좋지 않습니다. 커밋에 대한 책임을 잃을뿐만 아니라 모든 사람이 해당 키를 복사하여 다른 곳에서 사용할 수 있기 때문입니다. 그런 종류의 문제가 발생하면 코드 또는 diff를 로컬 컴퓨터에 복사하여 거기서 커밋합니다.

— 법 29

2

sudo머신의 일반 관리에 정확히 허용 되지 않는 이유는 무엇 입니까?

— Blacklight Shining

4

"매우 안전한 환경"oO에서 루트로 ssh?

— xaa

@BlacklightShining 당신이 아무것도 할 수 없다면 (chown, chmod 임의의 파일, 서버 설치, 파일 시스템 마운트, 사용자로 sshing하고 sudo bash를 수행하면 얻을 수있는 것이 없습니다. 대신, 로깅 릴레이를 사용하여 ssh 그리고 / 또는 ssh'd에

— 들어간

1

@xaa 예, 그렇습니다. 문제가 없습니다. 내가 입력 한 모든 내용은 다른 컴퓨터에 기록됩니다. "루트로 작동하지 않음"은 기계가 원하는 모든 것이 루트가되어야하는 서버 인 경우 완전히 쓸모없는 최대 값입니다.

— 법률 29

3

시스템의 사용 사례에 따라 다릅니다. 그것이 때때로 테스트를위한 시스템이라면 나에게 좋습니다. 우리는 또한 그러한 시스템을 가지고 있습니다. 회사에 어떤 종류의 ID 관리 (LDAP, IPA)도없는 경우 임의 시스템에서 원격 제어없이 새 사용자를 작성하는 것은 상당히 부담입니다.

그러나 누군가 실수로 회사 전체를 운영 할 수 없게 만드는 일상적인 일은 좋은 생각이 아닙니다.

— 자쿠지
소스

디렉터리 서비스가 없거나없는 경우 수천 개의 계정을 만들고 관리하는 것은 비현실적입니다.

— Jim B

LDAP를 사용할 수없는 경우에도 SSH 액세스 (또는 Windows의 Powershell)가있을 수 있습니다. (암호도 공유하지 않는 한) 모든 계정에 대해 호스트에서 authorized_keys 파일을 관리 할 수있는 방법과 수많은 다른 설정이 여전히 필요합니다. 왜 많은 종류의 사용자 또는 서버가 있다면 어떤 종류의 구성 관리 (예 : Puppet, Chef, Ansible)를 사용하지 않는지 궁금합니다. 이러한 부담을 없애고 대가로 프로세스 제어, 책임 및 감사 기능을 제공합니다.

— Martijn Heemels

3

이 모든 답변은 자체적으로 중요하고 실제적인 문제인 책임에 대한 우려를 해결하지만 공유 계정을 사용하면 다른 사용자에 대한 미묘한 공격도 허용됩니다.

침입자 ssh가 입력 한 암호를 기록 하는 악의적 인 스크립트를 만들어 PATH공유 된 사용자 (쉽게 수행)에 넣는 것을 고려하십시오 . 이제 공유 사용자로 해당 컴퓨터에 로그온하고 ssh다른 사람 (이번에는 개인의 공유되지 않은 계정으로)을 결정하는 다음 사람 이 놀라 울 수도 있습니다.

기본적으로 컴퓨터에서 공유 계정을 사용하는 것은 공공 수영장의 발 욕조에서 마시는 것과 같습니다.

— ereOn
소스

1

일반적으로 다음과 같은 이유로 하나의 계정을 공유하는 것은 좋지 않습니다.

이 사용자에 대한 모든 설정은 로그인하는 모든 사람에게 영향을 미칩니다. (Promt, aliases, ...)
1. 누가 무엇을했는지 알아낼 가능성을 잃습니다 (책임)
2. 계정 구성에서 실수 (예 : 실수로 ssh kay를 삭제하는 것)는 해당 사용자 계정을 사용하는 모든 사람에게 영향을 미칩니다 (예 : 잠금).

그리고 더 많은 단점이 있는지 확인하십시오 ... 그러나 나는 더 이상 들어가고 싶지 않습니다.

요점은 모든 관리자가 액세스 할 수있는 특정 사용자 계정으로 실행되는 서비스를 관리하기 위해 계정을 공유해야 할 필요성에 직면하고있을 수 있습니다.

이러한 설정에서는이 계정을 공유하여 로그인 할 수 있거나 (위의 재조정의 경우 오히려이를 수행하지 않을 것입니다) 개별적으로 로그인하여 사용자를 공유 계정으로 전환 할 수 있습니다 (제안 할 것입니다).

감사 도구를 사용하면 누가 여전히 같은 계정을 공유하고 실행했는지 추적 할 수 있습니다.

— 게르하르트
소스