How to gpg encrypt with ssh public key? - ssh

I have a public key in a file called key.pub, and the contents look like:
ssh-rsa AAAAB...<snip>...t+f klahnakoski
I would like to to use it to encrypt a file with gpg. What is the sequence of shell commands required?
I imagine the sequence looks something like:
convert key to gpg-friendly format
invent some credentials to sign key with
invent a user to facilitate adding key to keyring
perform the encryption
Thank you!

RSA keys can only be used to encrypt a proportion of their key length. e.g. a 2048 bit RSA key can only be used to encrypt about 245 bytes.
See:
https://security.stackexchange.com/questions/33434/rsa-maximum-bytes-to-encrypt-comparison-to-aes-in-terms-of-security
So to encrypt / decrypt large amounts of data (files) you would use a symmetric key which was encrypted using a public key, not the public key itself.
Also, you wouldn't add a symmetric key to a public SSH key, because the the symmetric key is a secret, and the public SSH key isn't a secret. The symmetric key should be added to the private SSH key.
It goes something like the following:
To convert the file format, install the monkeysphere tool set (Ubuntu)
sudo apt-get install monkeysphere
Use the pem2openpgp tool to convert the private key to gpg format. Pipe to gpg for import.
pem2openpgp userid-ssh#example.com < id_rsa | gpg --import
# Check it's there
gpg --list-secret-keys
Edit the trust level you have in the key.
gpg --edit-key userid-ssh#example.com
gpg> trust
Add the trust level you need (ultimate for example)
The key imported is only suitable for creating certificates, not for signing or encryption.
Encryption
The key is an RSA key and can't be used to encrypt / decrypt large amounts of data. If you want to do that you have to add a symmetric encryption subkey. When you encrypt, GPG will use this subkey rather than the original SSH key.
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
Your selection? 6
Now you can encrypt and decrypt using the identity based on the SSH key.
gpg -vv -r userid-ssh#example.com -e -a unencrypted_file.txt
So how useful is this?
Well, it makes more sense to use GPG to generate and manage your SSH keys as authentication subkeys rather than trying to do it the other way round. In fact it can be integrated into SSH instead of ssh-agent.

Probably ssh-vault could give you some ideas, it follows the same principle of PGP and using the public ssh keys to encrypt the password only.

Related

How can I determine the format of an ssh private key file?

I am developing an application that uses ssh keys (JSch), and it won't accept some ssh keys. I want to make guidelines to users so they know which keys they can use and which one they can't. Hence the question: how can I determine the format of an ssh private key file, going beyond the RSA/etc and the number of bits?
For instance, at the end of this question is a 3072 bit RSA key that was generated using ssh-keygen with no parameters on android/termux. it works in ssh but both JSch and JuiceSSH refuse to even open it. openssl rsa -text -noout -in file says:
unable to load Private Key
1991864336:error:0909006C:PEM routines:get_name:no start line:../crypto/pem/pem_lib.c:745:Expecting: ANY PRIVATE KEY
I can fix this by running ssh-keygen -p -m PEM -f file, and this might be a workaround for some users, but it would help to know in advance which formats work and which don't.
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAxeXW062gz3y29H9nni0pz+IDetDpMWxOsyLXAIJuyRrXNqmcsLTz
f2qMP4ua3ENkqjoa+wwv95Ft+X4eb920FoKCL4vzpSWgFH8MfCL8Szs1y0/vgzVEipBMCh
FwIXqtnFaTvVS69vgZKARspIEod9z/Qvh0fsz5xCHlGwL2xy5eiUL2gjLXcfQxJQft5oo8
POBFSjCxWUwuE7MrqiaFbSUk3ULVyBVwTAJdC363oYWD5DV2WlYvxsEFQREbn4yRVjvzfe
1hKeKA/JnzZVYrCLOt5hOBTppY0rSSsiGCvhX+hKNStgG2JMSheBfjytENZ3hx050vfL6Z
5zOib97Gb+5qygbtcVosYsfXK34zOiMdDOBojItw0s0aZ3nSF+D1l+XqBaeHIBeX3+JoyN
kYjH/JPC1/hykrbi0ueOmaYI2xmBrqT8Z7aUX3EyKSOWNOMAWTiPDB2SFpjoQHuznq7nFg
/8zBbAU6/J3u/28sivhKDHXZLcZ7aw8glm3fr5DzAAAFiDYAnjo2AJ46AAAAB3NzaC1yc2
EAAAGBAMXl1tOtoM98tvR/Z54tKc/iA3rQ6TFsTrMi1wCCbska1zapnLC0839qjD+LmtxD
ZKo6GvsML/eRbfl+Hm/dtBaCgi+L86UloBR/DHwi/Es7NctP74M1RIqQTAoRcCF6rZxWk7
1Uuvb4GSgEbKSBKHfc/0L4dH7M+cQh5RsC9scuXolC9oIy13H0MSUH7eaKPDzgRUowsVlM
LhOzK6omhW0lJN1C1cgVcEwCXQt+t6GFg+Q1dlpWL8bBBUERG5+MkVY7833tYSnigPyZ82
VWKwizreYTgU6aWNK0krIhgr4V/oSjUrYBtiTEoXgX48rRDWd4cdOdL3y+meczom/exm/u
asoG7XFaLGLH1yt+MzojHQzgaIyLcNLNGmd50hfg9Zfl6gWnhyAXl9/iaMjZGIx/yTwtf4
cpK24tLnjpmmCNsZga6k/Ge2lF9xMikjljTjAFk4jwwdkhaY6EB7s56u5xYP/MwWwFOvyd
7v9vLIr4Sgx12S3Ge2sPIJZt36+Q8wAAAAMBAAEAAAGAdd2LUq3R3mJAMWUEWOA7S/Yn7m
koymfgg67XcRU+WIak8YiZq2FKuXPDLkG+rTtyZDSRRz6d/wxd/L/R7vyTuuhmE11+crjz
G+IDlJfdvgz44Cuu0m3Scdi5gTGboEUJy9iAy74AUQG5Me1Yq63FZYZ5ffCuqar5g4hQhQ
MB6eXDJmt8mFUhnlw7PPv5BFsGv5cvjZ1ss2u88by/3+prg3Mg/qtE2pNyO8MYmbUSN6Bm
ym/RGsLEV9M0hulik2dLSFfChfywm0//fBfD3L2Gusvr+sh9xq3W3e6qYilmy/QhSNy1XV
brDFGAzqmTISoeblZscmAsA1bKvt3rsU0Lfkxom3NnyXvSGJ7LXy+tzInu873+p2gyCylB
c4KpepodLGI8xLH6RFiyV4g0sFWgFROE9eLSR1mNa8tA54jD6NzEoy6ThlLnwH00DKccb1
6zNK0aNaJyXVEOUd5D0OR3/XkH9DhSl1W0GMHP9Y4JVgxWp1YMFqqYOyQqt9zNGO1JAAAA
wQCb63qWGLJp4RKdCyqkE1gdp4ohcgeofkRZvTPHZ6cepXDYSrefoxbOiFg6AmvWmyJxW+
pqjDaDj1OBvk729JdqBDKI/VyGxp992hIVssllD/MTvJR4omepfj91HsWRmlMSkpeGBAre
2gxI6oRVT/J/6oegUATeQOGOMunZIv6Q1JKcda9/zjPL4Pg9xDzp+VyfoMZpLNKp1F2tzT
VC6SueiDR0INVhWLOtWUSMZCWrvhMQmwz5jreuzkNallEdb/YAAADBAOiPLZbhMvUGCwwu
qodmzHGAQ7TrG1ifF8s/6weENsr2SPAJ7t+nbjmjtwlq+Sb+ye49cRh2jElqFQ3ckJVWfA
3WFkv7T576o2/Duye023i2coPmaZ0V44Qf3jVnV2Dl3663E7bQt4xYCNU4Odaq4EdhBsyy
ey/jIRR13UVfWf3q9zRvOWEk5kaE92bN0L8AEX2CfV6cTSrV8oHxLSG1RAr4706jXXV/34
N4QYwfCap1GW2rcPUu7oX+RMOk8mMgnQAAAMEA2dhG3XHIHbScvSs9m/C5WjIJ+uBKNeP5
YODIoy9cy9oK9AUFWr+RlSRv1rlx2/y2krsojKI0Y/GEW/0aNt85vD400MMDAgKx4Nl99C
uVXXysH9Y0BjSKZ/bqnYN/FL6apWrTxS7s3ZJTkuHgjf1ymo3ySLUyYX4wkJtTx71BJFg5
6FlKmYZKu6JSIoIzDKR6Uaqb8s0HOgj9a9bf7kXBk2CWfYz1BU777NqQdZAJdJtSH52fXg
Rlk/d8DHNpBVrPAAAAEXUwX2ExNzFAbG9jYWxob3N0AQ==
-----END OPENSSH PRIVATE KEY-----

Encrypt with GPG without adding stuff to the encrypted file?

$ echo "helloworld" > text.txt
$ cat text.txt
helloworld
$ gpg --cipher-algo AES256 --symmetric --armor text.txt
gpg: gpg-agent is not available in this session
$ ls
text.txt text.txt.asc
$ cat text.txt.asc
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1
jA0ECQMCnGyzh+mRmpBg0kgBfcqLbdAhLc+xwZDta3/kudi/f6MmjXUzFUbNFr3H
IoXgqzjRqbeNESHd+nFSTxHQc8tXF80vXMdDzTy3HmD6ZWk3BvVx5Vo=
=EviP
-----END PGP MESSAGE-----
So, how can I avoid adding GPG stuff? I want only the encrypted bytes.
As AES256 is symmetric, I'd like to do something like this:
1. Apply AES with keyA to "file_original.txt" and produce "file_keyA.txt"
2. Apply AES with keyB to "file_keyA.txt" and get "file_keyA_keyB.txt"
3. Apply AES with keyA to "file_keyA_keyB.txt" and get "file_keyB.txt"
4. Apply AES with keyB to "file_keyB" and get "file_original.txt"
So, if I'm A, and want to send "sometext" to my friend B:
I send "sometext" encrypted with GPG with keyA to my friend.
He send back to me his text encrypted with his keyB too.
I decrypt with my keyA and send back to him.
He should apply keyB and get "sometext".
It should be possible if I use gpg with AES and my friend another software or another symmetric algorithm without knowing my keyA. But it's only possible if gpg (or his software) doesn't add stuff to the encrypted file. I want to apply only the algorithm AES, so I can encrypt multiple times with the same key and get the original.
Probably you want to use openssl instead of gnupg. For example:
openssl enc -aes128 -salt -in yyy -out yyy.enc
More information at the manpage: https://www.openssl.org/docs/man1.0.2/apps/enc.html
If you're looking to send an encrypted message to your friend with gpg, without sharing a passphrase that'd be used to decrypt the message, then you probably want to use asymmetric encryption. To do this, you and your friend will each need to generate PGP keys with
gpg --gen-key
then exchange your public keys
gpg -a --export "mykey" > mykey.pub
<trade mykey.pub files>
gpg --import theirkey.pub
then prepare your message for transmission
gpg -e -a -u "my key" -r "their key" --sign -o somefile.txt.gpg somefile.txt
after your friend has the message they'll need to decrypt it with
gpg -d -o somefile.txt somefile.txt.gpg
and they've got the message. GnuPG will generate a strong key, use that key to encrypt the message, then use your friend's key to encrypt that key and attach it to the file. It'll also use your private key to sign the file so your friend can be (reasonably) sure it wasn't tampered with in transit. In this example you can use
gpg --list-keys <or gpg -k>
to find their key handle (it's the bit after "rsa4096/" and before the creation date) to use in the quotes in the -r "their key" part, and
gpg --list-secret-keys <or gpg -K>
to find the handle of your key, to use in the -u "my key" part.
If you're really looking to use symmetric encryption and share a passphrase with your friend, then I'd also recommend openssl, like #pchris suggested.

Convert Ed25519 to RSA fingerprint (or how to find SSH fingerprint)

BizTalk sees thumbprint for an internal SFTP test as
ssh-rsa 2048 33:88:f0:ff:63:78:a9:2b:3f:09:cb:05:81:db:59:86
WinSCP shows: ssh-ed25519 256 ff:2e:5e:33:7a:15:de:69:18:cf:82:ae:f0:4e:7b:d2
(when I click "Session", then "Server/Protocol Information")
Is it possible to convert one to the other?
Is it possible to get the ssh-rsa thumbprint from WinSCP, PuTTY or some other tool?
WinSCP uses Ed25519 host key. It's a different key, than the RSA host key used by BizTalk. You cannot convert one to another.
WinSCP defaults to Ed25519 hostkey as that's preferred over RSA. You can only make WinSCP use RSA using raw session settings HostKey.
Alternativelly, if you can connect with SSH terminal (e.g. PuTTY) to the server, use ssh-keygen to display a fingerprint of the RSA host key:
ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
(this assumes common *nix server with OpenSSH)
Note that this makes sense only, if you had verified the host key, that the SSH terminal uses, upfront.
See WinSCP FAQ on Where do I get SSH host key fingerprint to authorize the server?, which covers all this.
ssh-rsa 2048 33:88:f0:ff:63:78:a9:2b:3f:09:cb:05:81:db:59:86
and
ssh-ed25519 256 ff:2e:5e:33:7a:15:de:69:18:cf:82:ae:f0:4e:7b:d2
Are same fingerprint types, but different key types (one is RSA and the other ED25519 -- elliptic curve). There is no way one to the other, because they are fingerprints of different keys.

In what format is the public key of a server stored in the known hosts?

When we ssh to a host, he is either known or not. In the latter case during our first try to connect we are prompted to
The authenticity of host '13x.8x.xx.1x1 (13x.8x.xx.1x1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:26:86:80:5f:17:xx:xx:xx:xx:6d:6c.
Are you sure you want to continue connecting (yes/no)? yes
Then the server's RSA public Key is stored in the .ssh/know_hosts file. How is it encoded? And how can we ensure that this is not a man-in-the-middle?
Finally, this so-called 'host key' is assymetric. What does this mean?
How can we ensure this is not a man-in-the-middle?
The first time, you can check the RSA fingerprint. Someone needs to previously communicate it to you, or you need to somehow receive it securely (ie published via a https site, or received via a signed email). Many hosting providers, for example, send you your hosts SSH fingerprint.
On Ubuntu, you can find your own RSA fingerprint using:
ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub
Note that there are other in-use fingerprint formats (dsa and ecdsa), depending on the server and client config. In your known_hosts file you can see the format in which each fingerprint has been stored.
How is it encoded?
The known_hosts file is a list of hostnames (or often, hashes of hostnames), the type of the fingerprint, and the fingerprint itself (cryptographic information) in base64 encoding. The format details can be found in the OpenSSH man page, under the SSH_KNOWN_HOSTS FILE FORMAT section.
This so-called 'host key' is asymmetric. What does this mean?
These asymmetric mechanisms mean that while the fingerprint allows you to verify the identity of the server, you cannot use it to generate a valid identification (to impersonate) that server.
It must be noted that the fingerprint (and the corresponding private key) are used as secret for cryptographic operations: a random challenge is sent from the client to the server. The server, which has the private key, can sign that challengue and send it back, then the client can verify the signature is valid because the fingerprint is appropriate.
In other words, the cryptographic secret is two-fold, the private key can cipher or sign, and the public key can be used to decipher or verify a signature. One of the keys can be made public at no risk, and used to verify signatures and to cipher text that only the owner of the private key will be able to decode. This is roughly what asymmetric means in cryptography.

Creating RFC-4716 specific dsa public-key using openssl

For the purpose of ssh using public key authentication,
DSA-2048 keypair has been generated using openssl and both are stored locally in PEM format.
Now, for configuring in the server side (authorized_keys), public key has to be in the RFC-4716 format.
Usually as a practice, for getting this key, ssh-keygen is typically used with options as,
ssh-keygen -y -f private_key.pem
which returns the corresponding public key(RFC-4716) that has to be configured in the server side.
Without ssh-keygen, Is there a possibility in openssl itself to generate the RFC-4716 specific public key from the openssl generated public (or) private key?