--require-authentication과 호환되는 원격 서명자로 베이킹?

Question

--require-authentication과 호환되는 원격 서명자로 베이킹?

- 10
- 128 2019-02-16
클라이언트 작업의 경우 --require-authentication으로 원격 서명자를 사용하려면 클라이언트 키의 복호화 비밀번호를 수동으로 입력해야합니다.

아무데도 문서화되어 있지 않습니다. 베이킹과 호환되지 않습니까?베이킹을 설정할 때 클라이언트 키를 해독 할 수있는 방법이 없으며 베이킹을 위해 인증이 우회되지 않는다고 가정합니다.

감사합니다

For client ops, using a remote signer with --require-authentication requires manually entering the client key's decryption password.

It's not documented anywhere -- is this incompatible with baking? There's no way that I'm aware of to decrypt the client key when setting up baking and I assume authentication isn't bypassed for baking.

Thanks

baking

- 알파넷에서는 인증 키에 대한 비밀번호를 입력하지 않고 작동하지만 메인 넷에서는 단말기에서 비밀번호를 요청하지만 비밀번호를 입력 할 단말기가 없기 때문에 실패합니다.나는 또한 이것에 대한 답을 찾고 있습니다.
  
  On alphanet it works without entering the password for the authentication key, but in mainnet it ask for password on terminal, but due to absence of any terminal to enter the password it fails. I am also looking out for an answer to this.
  - 0
  - 2019-02-22
  - Sachin Tomar
- tezos-signer 명령에서 --require-authentication 플래그를 사용하지 않으면 인증 방법을 우회 할 수 있습니다.인증 방법을 우회하는 경우에도 방화벽을 사용하여 서버 및 포트에 대한 액세스를 제한해야합니다.
  
  Although you can bypass the authentication method by not using --require-authentication flag in tezos-signer command. Make sure to restrict access to your server and port using firewall though if you bypass the authentication method.
  - 0
  - 2019-02-25
  - Sachin Tomar

3 대답

투표

- 3
- 2019-02-25
tezos 메인 넷에서는 암호화되지 않은 형식으로 키를 생성 할 수 없습니다.따라서 키를 해독하려면 암호를 입력해야합니다.

해결 방법은 암호화되지 않은 키를 가져온 다음 원격 서명자와의 통신을 인증하는 데 사용하는 것입니다. tezbox 지갑 을 사용하여 암호화되지 않은 키를 생성 한 다음 개인 키를 복사하고 아래 명령을 사용하여 내 서버로 가져 왔습니다.

./mainnet.sh client import secret key auth-alias unencrypted:edskxxxxxxxxxxxxxTnZR
On tezos mainnet, you cannot generate your key in unencrypted form. So you have to enter the password to decrypt the key.

Solution is to import an unencrypted key and then use is to authenticate any communication with remote-signer. I used tezbox wallet to generate unencrypted keys and then copy the private key and imported to my server using below command.

./mainnet.sh client import secret key auth-alias unencrypted:edskxxxxxxxxxxxxxTnZR
- 암호화되지 않은 암호화되지 않은 개인 키를 생성하고 다른 서버에 복사하는 것이 본질적으로 * 안전하지 않은 * 아닌가요?
  
  isn't it intrinsically *unsafe* to generate an unencrypted unencrypted private keys and copy this around for another server ?
  - 0
  - 2019-02-25
  - Ezy
- 예,이 키를 베이킹 키로 사용하면 안전하지 않습니다.그러나 여기에서 유일한 목적은 인증 키로 사용하는 것이지만,서버에 개인 키를 복사하는 동안 분명히 예방 조치를 취해야합니다.개인 키를 복사하고 싶지 않고 서버에서만 개인 키를 생성하려면 https://github.com/TezTech/eztz를 사용할 수 있습니다.
  
  Yes it is unsafe if you are using this key as baking key. But here the only purpose for this is to be used as authentication key, but obviously precautions need to be taken while copying your private key to the server. If you don't want to copy the private key and want to generate the private key on the server only you can use https://github.com/TezTech/eztz
  - 0
  - 2019-02-25
  - Sachin Tomar
- 어떻게 단순히 원장을 사용합니까?
  
  how abt simply using ledger ?
  - 1
  - 2019-02-25
  - Ezy
- 예,원장을 사용하는 것이 가장 안전한 방법이지만 원장에 대한 경험이 없습니다.이것에 대한 문서는 정말 도움이 될 것입니다.
  
  Yes using ledger would be most secure way but i don't have any experience with ledger. Any documentation for this would be really helpful.
  - 0
  - 2019-02-25
  - Sachin Tomar
- 여기 TSE에서 검색 할 수 있습니다. 시작하는 데 필요한 답변이 있습니다.예 : https://tezos.stackexchange.com/q/395/118 및 https://tezos.stackexchange.com/q/477/118.이것이 충분하지 않다면 새로운 질문을 자유롭게하십시오!
  
  you can search here on TSE there are answers to get you started. Eg: https://tezos.stackexchange.com/q/395/118 and https://tezos.stackexchange.com/q/477/118 . If this is not sufficient then feel free to ask a new question!
  - 0
  - 2019-02-25
  - Ezy
- 확실히 그는 암호화되지 않은 키를 사용하지 말아야합니다. 정말 끔찍한 생각입니다.
  
  Definetly he shouldn't use unencrypted keys - that's a really terrible idea.
  - 1
  - 2019-02-25
  - moonrider_unchained
- 네트워크에 액세스 할 수있는 컴퓨터에 암호화되지 않은 키를 갖는 것은 아마도 나쁜 생각 일 것입니다.
  
  It's probably a bad idea to have unencrypted keys on a network-accessible machine.
  - 0
  - 2019-02-26
  - latte_jed
- 1
- 2019-12-04
두 답변보다 보안을 강화하는 방법이 있습니다 (오늘 기준) https://tezos.stackexchange.com/a/607/29 (답변 A) 및 https://tezos.stackexchange.com/a/598/29 (답변 B)는 제안합니다.

서명자

매직 바이트 0x01,0x02 만 허용합니다.

서명자는 제빵사의 IP의 요청 만 수락하도록 방화벽이 설정되어 있습니다.

터널이 암호화되고 (권장)

암호화되지 않은 서명자 인증 키는 베이커에 남겨 두어도됩니다. 답변 B의 편리함을 얻을 수 있지만 서명자 인증 키 (답변 A)를 사용하는 보안이 추가되었습니다. 모든 가능성으로부터 사용자를 보호하지는 않습니다 (현재로서는 이러한 방법 중 하나 ),하지만 암호화되지 않은 서명자 인증 키를 사용하면 여전히 피할 수 있습니다. 잠재적 인 위험이 있습니다. 예를 들어,악성 머신이 IP를 획득 한 경우 (예 : 실수로 IP를 해제하거나 호스트가 IP 경로를 잘못 지정하는 경우) 공격자는 단순히 이중 베이크/승인조차 할 수 없습니다.

어떤 사람들은 약간의 이득을 위해 더 많은 일이라고 말할 수 있지만 저는 약간 편집증이 있고 쉬운 길을 택하고 싶지 않습니다.

요점,--require-authentication은 다른 예방 조치를 대체하지 않습니다.
There is a way to have more security than both answers (as of today) https://tezos.stackexchange.com/a/607/29 (Answer A) and https://tezos.stackexchange.com/a/598/29 (Answer B) suggest.

If the signer

only accepts magic bytes 0x01,0x02,

and the signer is firewalled to only accept request from the baker's IP

and the tunnel is encrypted (preferably),

it is ok to leave the unencrypted signer auth key in the baker. You get the convenience of answer B, but with the added security of using a signer auth key (answer A). It doesn't protect you against every possibility (it is not possible at this time to pass the password to the baker/endorser, AFAIK even using one of these methods), but by having an unencrypted signer auth key you are still avoiding some potential risks . For example, if a rogue machine obtains your IP (say you release the IP by accident, or your host misroutes your IP) the attacker still won't be able to even simply double bake/endorse.

Some might say it is more work for little gain, but I am a bit paranoid and don't like to take the easier route.

Bottom line, --require-authentication is not a substitute for other precautions.
- 출처
- Gaia

latte_jed · Accepted Answer · 2019-02-26

2

2019-02-26

댓글에서 언급 한대로 이에 대한 가장 정답은 다음과 같습니다.

아니요,베이킹을 위해 서명자와 함께 --require-authentication을 사용할 수 없습니다.TTY가 없으며 보증/베이킹 작업을 실행해야 할 때 인증 키를 해독 할 수 없습니다.

여기에서 가장 좋은 방법은 서명자와 제빵사 사이에 암호화 된 터널을 사용하고 서명자가 네트워크에 직접 액세스 할 수 없도록하는 것입니다.