7

tezos-signer supports --require-authentication, --magic-bytes, and --check-high-watermark options. You should understand these. $ tezos-signer man -v 3 ... -A --require-authentication: Require a signature from the caller to sign. ... -M --magic-bytes <0xHH,0xHH,...>: values allowed for the magic bytes, defaults to any -W --check-high-...


6

I figured out that you can use the --dry-run option in the transfer statement so that node will send transaction to remote-signer to sign, and you can check the remote-signer logs to see if everything is working fine or not. --dry-run will not actually send the transaction to the network.


4

I just prefer to do this...it's a direct request to sign data without any possibility of forgetting to add the --dry-run flag. tezos-client sign bytes 0x03 for <tz alias or tz address> Here 0x03 is just any old random number. You could put any hex value here. If the remote signer is working you'll get back a message like: Signature: ...


3

edit: only tried locally, not remote. I suggest you try signing dummy bytes. This will fail. But the way how it fails will tell you if your ledger is connected in the right way and if your signer still responses. tezos-client sign bytes 0x03 for "<my_ledger_address>" Will give you the error you got if the ledger is in baking mode, looking like this:...


3

It's outlined in the tezos docs here: https://tezos.gitlab.io/mainnet/introduction/various.html#signer One thing you need to think about is setting up a VPN or ssh tunnel or some secure connection between the signer (running on a local machine with the ledger connected) and the node in the cloud. I can recommend taking a look at Zerotier - https://www....


3

I recommend using HTTP or HTTPS as it is a standard protocol so easier to handle, debug and test. Using a TCP socket means you have to understand that protocol and write specific tools for monitoring (assuming you will be monitoring).


2

0x03 is for generic operations, like transfers. The ledger baking app cannot sign 0x03; it will only sign bytes beginning with 0x01, and 0x02 (blocks, endorsements). You need to exit the baking app and load the wallet app on your ledger in order to execute transfers.


2

The error logs clearly suggest that the ENOTTY error for the "auth" key is your problem. You cannot directly use an encrypted key to authenticate the docker daemons to a remote signer, because you cannot type the password in. (As FLF OCP notes, "the ENOTTY error is coming from an attempt to ask the key password on a terminal, but there is no such terminal")....


1

I answered a similar question previously. My previous answer was not specific to a ledger, but it should work just fine all the same. tezos-client sign bytes 0x03 for <tz alias or tz address> Here 0x03 is just any old random number. You could put any hex value here. If the signer is working you'll get back a message like: Signature: ...


1

I had the exact same error. My install is not the Docker-images but the classic install documented here: https://github.com/tezoscommunity/FAQ/blob/master/Compile_Mainnet.md My issue turned out to be that I run the tezos-signer via Screen, and the Screen session (not just the tezos-signer program inside it) needs to be restarted to see the new tezos-signer ...


1

If you use tezos-signer remotely, and set the option to require authentication, then you probably updated the node to the latest mainnet but you did not update the remote signer code, be sure it is updated. Sometimes it is not required, but the voting update seem to have changed something in authentication between remote signer and endorser/baker. I did ...


1

Another option would be to use Kiln. Kiln monitors your baker and will notify you if you miss any baking or endorsement opportunities (which will indicate that the signer is down). It can be found here.


Only top voted, non community-wiki answers of a minimum length are eligible