Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Monday April 06 2020, @06:46PM   Printer-friendly
from the on-behalf-of dept.

SSH key forwarding is to be avoided when possible. When it is not possibile to avoid, it is a good idea to limit what gets forwarded. Software developer Vincent Bernat describes one way by putting a simple shell script wrapper around the SSH client to provide a session with a unique, ephemeral key agent.

ssh-agent is a program to hold in memory the private keys used by SSH for public-key authentication. When the agent is running, ssh forwards to it the signature requests from the server. The agent performs the private key operations and returns the results to ssh. It is useful if you keep your private keys encrypted on disk and you don't want to type the password at each connection. Keeping the agent secure is critical: someone able to communicate with the agent can authenticate on your behalf on remote servers.

ssh also provides the ability to forward the agent to a remote server. From this remote server, you can authenticate to another server using your local agent, without copying your private key on the intermediate server. As stated in the manual page, this is dangerous!

Perhaps another approach would be to embed the wrapper in the ProxyCommand configuration directive, thus obviating the need for either a shell alias or shell function.

How and why have soylentils had to deal with SSH agent forwarding?

Previously:
(2019) How SSH Key Shielding Works
(2019) SSH Gets Protection Against Side Channel Attacks
(2018) Default OpenSSH-Portable RSA Private Key Encryption is Poor
(2017) SSH vs OpenVPN for Tunneling
(2016) Upgrade Your SSH Keys
(2015) Why Aren't We Using SSH for Everything?


Original Submission

Related Stories

Why Aren’t We Using SSH for Everything? 35 comments

SSH is a great tool many people are familiar with, but many more people aren't. Even if you use ssh daily, Why aren’t we using SSH for everything? is a great introduction to many things ssh does now, and what it could be used for in the future. One humble example is an ssh-chat server. The icing on the cake? The source for ssh-chat is open.

Upgrade Your SSH Keys 24 comments

Arthur T Knackerbracket has found the following story:

Whether you're a software developer or a sysadmin, I bet you're using SSH keys. Pushing your commits to Github or managing your Unix systems, it's best practice to do this over SSH with public key authentication rather than passwords. However, as time flies, many of you are using older keys and not aware of the need to generate fresh ones to protect your privates much better. In this post I'll demonstrate how to transition to an Ed25519 key smoothly, why you would want this and show some tips and tricks on the way there.

If you've created your key more than about four years ago with the default options it's probably insecure (RSA < 2048 bits). Even worse, I've seen tweeps, colleagues and friends still using DSA keys (ssh-dss in OpenSSH format) recently. That's a key type similar to RSA, but limited to 1024 bits size and therefore recommended against for a long time. It's plainly insecure and refused for valid reasons in recent OpenSSH versions (see also the changelog for 7.0).

The sad thing about it is that I see posts on how to re-enable DSA key support rather than moving to a more secure type of key. Really, it's unwise to follow instructions to change the configuration for PubkeyAcceptedKeyTypes or HostKeyAlgorithms (host keys are for a later post). Instead, upgrade your keys!

Compare DSA with the technology of locks using keys like this one. You wouldn't want this type of key to unlock your front door, right?

List all your keys:

You're probably thinking... "I'm using my key for a long time, I don't want to change them everywhere now." Valid point, but you don't have to! It's good to know you can have multiple keys on your system and your SSH client will pick the right one for the right system automatically.

It's part of the SSH protocol that it can offer multiple keys and the server picks the one your client will have to prove it has possession of the private key by a challenge. See it in action adding some verbosity to the SSH connect command (-vvv). Also if you're using an SSH agent you can load multiple keys and it will discover them all. Easy as that.


Original Submission

SSH vs OpenVPN for Tunneling 19 comments

http://blog.backslasher.net/ssh-openvpn-tunneling.html

The Story

I was asked to take care of a security challange - setup Redis replication between two VMs over the internet.
The VMs were in different continents, so I had keep the bandwidth impact to a minimum. I thought of 3 options:

        stunnel, which uses tunnels TCP connections via SSL
        SSH, which has TCP tunneling over it's secure channel (amongst its weponary)
        OpenVPN, which is designed to encapsulate, encrypt and compress traffic among two machines

I quickly dropped stunnel because its setup is nontrivial compared to the other two (no logging, no init file...), and decided to test SSH and OpenVPN.
I was sure that when it comes to speed, OpenVPN will be the best, because:

        The first Google results say so (and they even look credible)
                http://superuser.com/a/238801
                http://security.stackexchange.com/a/68367
                http://support.vpnsecure.me/articles/tips-tricks/comparison-chart-openvpn-pptp-ssh-tunnel
        Logic dictates that SSH tunneling will suffer from TCP over TCP, since SSH runs over TCP, [while] OpenVPN, being a VPN software, is solely designed to move packets from one place to another.

I was so sure of that, that I almost didn't test [but, after testing, the results showed that as] long as you only need one TCP port forwarded, SSH is a much faster choice, because it has less overhead. I was quite surprised.


Original Submission

Default OpenSSH-Portable RSA Private Key Encryption is Poor 15 comments

The Latacora firm has a blog post asserting that OpenSSH-portable has poor defaults for encrypting private RSA keys because of its reliance on OpenSSL. The blog goes into why this is a problem and how you can test it for yourself.

There is nothing wrong with the generated RSA keys themselves, however, just the encryption of the private RSA keys -- if made using current defaults. There are two ways of encrypting RSA keys, an old and apparently insecure way, and a new key format available but not default. Newer key types like Ed25519 use only the new key format and are not bothered by this problem.

Earlier on SN:
WikiLeaks Unveils CIA Implants That Steal SSH Credentials From Windows, Linux PCs (2017)
Upgrade Your SSH Keys (2016)
OpenSSH 6.8 Will Feature Key Discovery and Rotation for Easier Switching to DJB's Ed25519 (2015)


Original Submission

SSH Gets Protection Against Side Channel Attacks 6 comments

Submitted via IRC for Bytram

SSH gets protection against side channel attacks

Damien Miller (djm@) has just committed a new feature for SSH that should help protect against all the various memory side channel attacks that have surfaced recently.

Add protection for private keys at rest in RAM against speculation and memory sidechannel attacks like Spectre, Meltdown, Rowhammer and Rambleed. This change encrypts private keys when they are not in use with a symmetic key that is derived from a relatively large "prekey" consisting of random data (currently 16KB).

[...] Many thanks to Damien and all the others involved for working on this improvement!


Original Submission

How SSH Key Shielding Works 11 comments

On June 21, 2019, support for SSH key shielding was introduced into the OpenBSD tree, from which the OpenSSH releases are derived. SSH key shielding is a measure intended to protect private keys in RAM against attacks that abuse bugs in speculative execution that current CPUs exhibit.[0] This functionality has been part of OpenSSH since the 8.1 release. SSH private keys are now being held in memory in a shielded form; keys are only unshielded when they are used and re‐shielded as soon as they are no longer in active use. When a key is shielded, it is encrypted in memory with AES‐256‐CTR; this is how it works: [...]

https://xorhash.gitlab.io/xhblog/0010.html


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Funny) by Anonymous Coward on Monday April 06 2020, @08:00PM (2 children)

    by Anonymous Coward on Monday April 06 2020, @08:00PM (#979752)

    >> How and why have soylentils had to deal with SSH agent forwarding?

    I print out the ssh private key and send it by interoffice mail to the office where the server is located, and then ask Kumir to enter it into the server for me. I do the same for him, so it all works out in the end.

    • (Score: 0) by Anonymous Coward on Monday April 06 2020, @10:50PM

      by Anonymous Coward on Monday April 06 2020, @10:50PM (#979800)

      Kumir kopies it to Karachistan. Oh dear, oh me, oh my - however did they hack our systems?

    • (Score: 2) by MostCynical on Tuesday April 07 2020, @12:19AM

      by MostCynical (2589) on Tuesday April 07 2020, @12:19AM (#979820) Journal

      bonus points for using a privacy envelope and spelling Kumir's name correctly.

      --
      "I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
  • (Score: 1, Insightful) by Anonymous Coward on Monday April 06 2020, @09:07PM (1 child)

    by Anonymous Coward on Monday April 06 2020, @09:07PM (#979768)

    This seems like a job for kerberos....

    • (Score: 0) by Anonymous Coward on Monday April 06 2020, @09:59PM

      by Anonymous Coward on Monday April 06 2020, @09:59PM (#979785)

      It has its uses. For example, we use it to kick off jobs using RemoteCommand on servers that we don't want to have those credentials resting on. Easier than a similar kerberos setup.

  • (Score: 2, Interesting) by Anonymous Coward on Tuesday April 07 2020, @01:59AM (4 children)

    by Anonymous Coward on Tuesday April 07 2020, @01:59AM (#979842)

    With either the newer (2016) ProxyJump, or ProxyCommand with netcat or socat, you can traverse multiple jump hosts, and never expose your keys.

    I've never seen a situation where agent key forwarding was ever required.

    I used to have a bastion host at work that required a port knock. The script for ProxyCommand would check if host was directly reachable (on-site / vpn up), if not it would do the port knock, and then automatically traverse a second internal jump host-- all completely transparent when I used it. I would just 'ssh hostx'

    openssh is pretty damn amazing at what you can do with it. Well worth spending a few minutes with its man page.

    • (Score: 0) by Anonymous Coward on Tuesday April 07 2020, @06:25AM (3 children)

      by Anonymous Coward on Tuesday April 07 2020, @06:25AM (#979905)

      doesn't port forwarding simplify access to gitlab type of stuff? I log into the cluster, get disconnected, I'd like to not load the key all over again when I reconnect. Also I may have several terminals logged into the cluster because I want to edit multiple source files.
      what would the alternative to key forwarding be? honestly asking.

      • (Score: 0) by Anonymous Coward on Tuesday April 07 2020, @11:20AM (2 children)

        by Anonymous Coward on Tuesday April 07 2020, @11:20AM (#979934)

        If you want to log back into the same machine again quickly after disconnection then a key in an agent is the way to go.

        If you want to rapid fire concurrently connect to the same machine repeatedly then multplexing is the way to go.

        If you need to pass through a machine to get to others behind it, then ProxyJump is the way to go.

        Any of those can be combined.

        Can you give a sanitized set of commands illustrating your workflow connecting to or through GitLab?

        • (Score: 0) by Anonymous Coward on Tuesday April 07 2020, @02:35PM (1 child)

          by Anonymous Coward on Tuesday April 07 2020, @02:35PM (#979966)

          main usage type: I'm on laptop. I work on code, push to gitlab. I then connect to cluster (.ssh/config proxy thing), and pull code from gitlab.

          it may happen that I connect to interactive node of cluster at the same time as regular frontend (one for editing, one for running code), or similar.

          and it does happen that I need to synchronize between work desktop (vpn + ssh), cluster and laptop within a few minutes.

          for me using agent forwarding simplifies things a lot. I assume all is put on the laptop ssh-agent, even when I ssh-add a key from the cluster I can leave the ssh session, then when I log back in the key is still available.

          • (Score: 0) by Anonymous Coward on Tuesday April 07 2020, @03:48PM

            by Anonymous Coward on Tuesday April 07 2020, @03:48PM (#979981)

            I'll show my ignorance and admit I am not familiar with GitLab yet.

            Can you try using ProxyJump instead? That can be set in ~/.ssh/config

            Here you would write 'ssh cluster' to hop through the front end and reach the cluster:

            Host cluster
                            Hostname cluster.gitlab.com
                            IdentitiesOnly yes
                            IdentityFile whatever
                            AddKeysToAgent yes
                            ProxyJump account@frontend.gitlab.com

            If you can leave a connection to the frontend open and use it for repeated passthroughs to the cluster, then you can make it into a master connection and multiplex subsequent connections over it. That will save a little time if you are constantly rebuilding connections.

(1)