#pubkey

[ushf]

Given SSH pub and priv keys find their length and algorithm

The goal of this post is to show how to get some details about existing OpenSSH keys. To provide a sample it will start off with generating a possibly more secure key as recommended by this excellent blog. As regards whether it is best to move to other algorithms and longer key types Daniel Pocock argues that it may not be necessary. Note also the potential problems with some ssh-agents and interoperability with related infrastructure when moving from RSA 2048 bit to RSA 4096 bit. Note also that the generation example below specifically chooses SSH protocol 2 which is no-PEM compatible.

ssh-keygen -o -a 100 -t ed25519

# From "man ssh-keygen" -o Causes ssh-keygen to save SSH protocol 2 private keys using the new OpenSSH format rather than the more com‐ patible PEM format. The new format has increased resistance to brute-force password cracking but is not sup‐ ported by versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private key format. -a rounds When saving a new-format private key (i.e. an ed25519 key or any SSH protocol 2 key when the -o flag is set), this option specifies the number of KDF (key derivation function) rounds used. Higher numbers result in slower passphrase verification and increased resistance to brute-force password cracking (should the keys be stolen).

Then take a look at the key properties. Can do this with either the public or private key.

ssh-keygen -lf ~/.ssh/id_ed25519.pub 256 40:dd:09:3f:0a:6d:85:4a:33:c9:41:1b:3e:ea:b2:28 ush@testdribble (ED25519)

Note: as of Nov 2016 the OpenSSL suite does not support working with this Edwards twisted-curve function, so we cannot do something like "openssl ed25516 -text -noout -in /path/to/.ssh/ed25519". Patches are being reviewed upstream.

[ushf]

GPG key fingerprint without import

UPDATE/EDIT: Werner Koch explained on 04-JUL-2017 that for GnuPG >= 2.1.14 it is best not to rely on the --with-fingerprint as it was undefined behaviour. Instead we should do a dry run import (-n == no changes):

gpg -n --import --import-options import-show FILE_WITH_KEY This tells the import command to list the key during input (import-show) and not to actually import (-n or --dry-run)

More details how the manipulation of keys without adding them to the keyring are available in the release notes for 2.1.14 in the section Using GPG as a Filter which notes:

Since version 2.1.14 the export and import options have been enhanced to allow the use of gpg to modify a key without first storing it in the keyring.

--with-fingerprint Same as the command --fingerprint but changes only the format of the output and may be used together with another command.

I found that for GnuPG 2.0.30, libcrypt-1.7.3 that a key which I had not yet imported could show its fingerprint only when using the option --with-fingerprint. Surprisingly, given the above wording, the flag --fingerprint simply reported:

gpg: error reading key: No public key

for the exact same key.

I assume the manual should be re-worded slightly to make this difference more apparent.

See also this post which says importing is fine as long as you are careful about the trust metric.

[ushf]

GnuPG fingerprint pubkey

Often it is suggested that we first import a pubkey and then examine its signature. This is fine, except that I do not want my keychain ballooning in size un-necessairly.

So, if I download someone's pubkey, before I do anything else I often wish to check its fingerprint. Usually I forget how, so here is a quick reminder:

gpg --with-fingerprint someone-pubkey.asc

Using just

gpg someone-pubkey.asc

outputs the short ids and info.

[ushf]

Showing SSH pubkey and fingerprints

Showing the fingerprints of keys stored in ssh-agent

$ ssh-add -l

4096 0d:fg:56:98:2f:ef:7f:8d:5f:31:d6:31:31:13:fc:9d [email protected] (RSA)

2048 0a:eb:70:98:2f:g2:3f:da:c4:71:e6:32:23:g2:ff:e5 /home/me/.ssh/id_rsa (RSA)

Showing the fingerprints and random art for all pubkeys known at present.  (see "man ssh").  

 ssh-keygen -lv -f ~/.ssh/known_hosts

Copy a particular key to a remote server.  This can be done by manually scp'ing the key to $remote-location ~/.ssh/authorized-keys and setting the permissions properly to chmod 600  ~/.ssh/authorized-keys, or the copy-id script can be used:

ssh-copy-id -i ~/path/to/pubkey  username@remote-location

This is from the horse's mouth:

https://kimmo.suominen.com/docs/ssh/

The links below are written by Daniel Robbins (of Gentoo fame) and cover the issues of running ssh-agent.  Well worth reading:

http://www.ibm.com/developerworks/linux/library/l-keyc/index.html

http://www.ibm.com/developerworks/linux/library/l-keyc2/

http://www.ibm.com/developerworks/library/l-keyc3/

[chul-won]

개인키와 SSH Agent를 이용한 로그인

서버의 안정성을 위해 방화벽을 통해 집과 사무실을 제외한 모든 원격지에서는 SSH로 접근할 수 없도록 했는데, 사람이 어찌 한 장소에서만 일을 할 수 있으리요.. 종종 근처 카페에서 작업할 때 마다 방화벽 설정을 변경해줘야 하는 불편함이 있어 차라리 22번 포트를 모두에게 공개하고, 개인키를 가지고 있는 원격지에서만 접속할 수 있도록 처리했다.

[CLIENT]

$ ssh-keygen -t rsa

$ scp ~/.ssh/id_rsa.pub [USER]@[HOST]:/root/

[SERVER]

# cat id_rsa.pub >> .ssh/authorized_keys

# vi /etc/ssh/sshd_config

   RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFiles %h/.ssh/authorized_keys

PasswordAuthentication no

공개키가 아니면 일반적인 비밀번호로 접속이 불가능하도록 설정을 변경한다.

이 설정을 바로 바꿔버리면, 혹시나 개인키에 문제가 생겼을 때 접속이 불가능하니 먼저 개인키를 통해 접속이 가능한지 먼저 확인해야한다.

# service ssh restart