如何更改 ssh 密钥上的密码

Question

This question was migrated from Stack Overflow because it can be answered on Unix & Linux Stack Exchange. Migrated yesterday .

When I tried to change my password on an ssh key, I received the following error message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/username/.ssh/id_rsa' are too open. 
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

What does it mean? How can I fix this?

Edit: This solved my problem

sudo chmod 600 ~/.ssh/id_rsa

Answer 1

Choose the algorithm that is the quickest, since you probably care about doing this in real time. Generally for smaller blocks of data, the algorithms compress about the same (give or take a few bytes) mostly because the algorithms need to transmit the dictionary or Huffman trees in addition to the payload.

I highly recommend Deflate (used by zlib and Zip) for a number of reasons. The algorithm is quite fast, well tested, BSD licensed, and is the only compression required to be supported by Zip (as per the infozip Appnote). Aside from the basics, when it determines that the compression is larger than the decompressed size, there's a STORE mode which only adds 5 bytes for every block of data (max block is 64k bytes). Aside from the STORE mode, Deflate supports two different types of Huffman tables (or dictionaries): dynamic and fixed. A dynamic table means the Huffman tree is transmitted as part of the compressed data and is the most flexible (for varying types of nonrandom data). The advantage of a fixed table is that the table is known by all decoders and thus doesn't need to be contained in the compressed stream. The decompression (or Inflate) code is relatively easy. I've written both Java and Javascript versions based directly off of zlib and they perform rather well.

The other compression algorithms mentioned have their merits. I prefer Deflate because of its runtime performance on both the compression step and particularly in decompression step.

A point of clarification: Zip is not a compression type, it is a container. For doing packet compression, I would bypass Zip and just use the deflate/inflate APIs provided by zlib.

Answer 2

If you want to "compress TCP packets", you might consider using a RFC standard technique.

• RFC1978 PPP Predictor Compression Protocol
• RFC2394 IP Payload Compression Using DEFLATE
• RFC2395 IP Payload Compression Using LZS
• RFC3173 IP Payload Compression Protocol (IPComp)
• RFC3051 IP Payload Compression Using ITU-T V.44 Packet Method
• RFC5172 Negotiation for IPv6 Datagram Compression Using IPv6 Control Protocol
• RFC5112 The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)
• RFC3284 The VCDIFF Generic Differencing and Compression Data Format
• RFC2118 Microsoft Point-To-Point Compression (MPPC) Protocol

There are probably other relevant RFCs I've overlooked.

Answer 3

This is a follow-up to Rick's excellent answer which I've upvoted. Unfortunately, I couldn't include an image in a comment.

I ran across this question and decided to try deflate on a sample of 500 ASCII messages that ranged in size from 6 to 340 bytes. Each message is a bit of data generated by an environmental monitoring system that gets transported via an expensive (pay-per-byte) satellite link.

The most fun observation is that the crossover point at which messages are smaller after compression is the same as the Ultimate Question of Life, the Universe, and Everything : 42 bytes.

To try this out on your own data, here's a little bit of node.js to help:

const zlib = require('zlib')
const sprintf = require('sprintf-js').sprintf
const inflate_len = data_packet.length
const deflate_len = zlib.deflateRawSync(data_packet).length
const delta = +((inflate_len - deflate_len)/-inflate_len * 100).toFixed(0)
console.log(`inflated,deflated,delta(%)`)
console.log(sprintf(`%03i,%03i,%3i`, inflate_len, deflate_len, delta))

Answer 4

All of those algorithms are reasonable to try. As you say, they aren't optimized for tiny files, but your next step is to simply try them. It will likely take only 10 minutes to test-compress some typical packets and see what sizes result. (Try different compress flags too). From the resulting files you can likely pick out which tool works best.

The candidates you listed are all good first tries. You might also try bzip2.

Sometimes simple "try them all" is a good solution when the tests are easy to do.. thinking too much sometimes slow you down.

Answer 5

You may test bicom . This algorithm is forbidden for commercial use. If you want it for professional or commercial usage look at "range coding algorithm".

Answer 6

While fftcc's answer gives you detailed instructions how to make your permissions conforming to ssh's requirements, it may be useful to understand just why these requirements exist.

You can think of a pair of private/public keys as a secret and a test .

The secret is the private key: It is only known to you. It is like a door key. It fits in exactly one lock. The lock tests the secret : The public key is able to verify the private key. (The actual cryptography is more interesting: The public key can test the private key without knowing it, which a door lock cannot do.)

The door lock is public: Everybody can see it and try to put their key in it (and trust me, they do), but it will only ever accept the right one.

If you let people copy the private key (or your door key), they can enter your server (or your house). Therefore, nobody may read that private key.

As explained in the other answer, write permissions in any directory above the secret let a user recursively acquire permissions until they reach the secret, which is why ssh imposes requirements even on the user's home directory above it, which seems weird at first. By the way, I'm not sure whether ssh simply assumes or checks that the directories above the user's home directory are also write protected for the public: That's not necessarily a given.

From these principles the necessary permissions for the various files make mostly sense. A certain complication arises because one would assume that some files like authorized_keys, especially on the server side, need third party read access so that sshd can read them. But sshd runs as root — it opens a socket on a privileged address, after all — and can read anything it desires, independent of file permissions.

By the way, this implies that your local system admin intern can read your secret keys which you use to access your bitcoin wallet, chmod 600 my butt. For that reason it is possible to encrypt your private key, which seems... redundant at first but makes perfect sense if you have seen our admin. This question was actually concerned with encrypting the private key; the permission issues were purely incidental.

Answer 7

sudo ssh-keygen -f ~/.ssh/YOU_PRIVATE_SSH_KEY -p

If the terminal displays the message Permissions 0644 then run the command as root

If the terminal displays the message failed: Permission denied

To fix permission issues, first you need to set the correct ownership and permissions for the home directory and directory .ssh : ¹

sudo chown -R user:user $HOME sudo chmod 750 $HOME sudo chmod -R 700 $HOME/.ssh This creates the permissions for all files in.ssh necessary to satisfy SSH requirements. SSH recommendations and requirements (underlined) for individual directory files.ssh are listed below (from the manual page):

~/.ssh/id_rsa (or any PRIV KEY — private, primary key) — These files contain sensitive data [namely your authentication secret] and should be readable by the user, but not accessible for others (read/write/execute) — eg 0600. The ssh program will simply ignore the private key file if it is accessible by others.

sudo chmod 600 ~/.ssh/id_rsa

~/.ssh/config — due to the possibility of abuse, this file must have strict permissions: read/write for the user and not writable for others - it is enough to install 0644.

sudo chmod 644 ~/.ssh/config

~ /.ssh/authorized_keys — This file is not highly sensitive, but the recommended read and write permissions for the user and are not writable for others are 0644. ²

sudo chmod 644 ~/.ssh/authorized_keys

~ /.ssh/known_hosts — This file is not highly sensitive, but read and write permissions are recommended for the user and read-only for others, hence 0644.

chmod 644 ~/.ssh/known_hosts

~/.ssh/ — There is no general requirement to keep all the contents of this directory secret, but the recommended read/write/execute permissions are for the user and inaccessible for others — 0700 is enough.

sudo chmod 700 ~/.ssh

~ /.ssh /id_rsa.pub (OR ANY PUBLIC KEY) — These files are not confidential and can (but not necessarily) be readable by anyone.

---

¹ Write permissions to a directory lets a user change the permissions of the files and directories it contains. .ssh contains the secret private key which must not be known by anybody except the owner. If a different user had write access to the containing directory ( .ssh ) they could change the permission of the secret key in that directory and read the file. This argument recursively applies all the way up to the file system root.

² Even though authorized_keys does not contain strict secrets — all keys in it are public — it specifies who can log in: Anybody with the (unknown but verifiable) private keys associated with the public keys listed in the file. Therefore, write privilege to authorized_keys must be restricted to the account owner.

Answer 8

我认为文件大小并不重要——如果我没记错的话，GIF 中的 LZW 会每 4K 重置一次它的字典。

Answer 9

ZLIB should be fine. It is used in MCCP.

However, if you really need good compression, I would do an analysis of common patterns and include a dictionary of them in the client, which can yield even higher levels of compression.

Answer 10

I've had luck using zlib compression libraries directly and not using any file containers. ZIP, RAR, have overhead to store things like filenames. I've seen compression this way yield positive results (compression less than original size) for packets down to 200 bytes.

Answer 11

You can try delta compression . Compression will depend on your data. If you have any encapsulation on the payload, then you can compress the headers.

Answer 12

Form the man page:

ssh-keygen -p [-f keyfile] [-m format] [-N new_passphrase]
                   [-P old_passphrase]

Answer 13

I did what Arno Setagaya suggested in his answer: made some sample tests and compared the results.

The compression tests were done using 5 files, each of them 4096 bytes in size. Each byte inside of these 5 files was generated randomly.

IMPORTANT: In real life, the data would not likely be all random, but would tend to have quiet a bit of repeating bytes. Thus in real life application the compression would tend to be a bit better then the following results.

NOTE: Each of the 5 files was compressed by itself (ie not together with the other 4 files, which would result in better compression). In the following results I just use the sum of the size of the 5 files together for simplicity.

I included RAR just for comparison reasons, even though it is not open source.

Results: (from best to worst)

LZOP: 20775 / 20480 * 100 = 101.44% of original size

RAR : 20825 / 20480 * 100 = 101.68% of original size

LZMA: 20827 / 20480 * 100 = 101.69% of original size

ZIP : 21020 / 20480 * 100 = 102.64% of original size

BZIP: 22899 / 20480 * 100 = 111.81% of original size

Conclusion: To my surprise ALL of the tested algorithms produced a larger size then the originals!!! I guess they are only good for compressing larger files, or files that have a lot of repeating bytes (not random data like the above). Thus I will not be using any type of compression on my TCP packets. Maybe this information will be useful to others who consider compressing small pieces of data.

EDIT: I forgot to mention that I used default options (flags) for each of the algorithms.