Comment by m463 | Hacker News Reader

Comment by m463 | Hacker News Reader

I always create and heavily use ~/.ssh/config

   Host x
       Hostname full.host.name.com  (or 1.2.3.4)
       User <myuser>
       IdentitiesOnly yes
       IdentityFile ~/.ssh/id_x_ed25519

I give hosts short names so you can `ssh x`

to do automatic login, I generate identities for some machines

  ssh-keygen -t ed25519 -f ~/.ssh/id_x_ed25519

use ssh-copy-id to copy the identity to the target machine so it lets you in:

  ssh-copy-id -i ~/.ssh/id_x_ed25519.pub x

or if your machine doesn't have ssh-copy-id (older macs);

  cat ~/.ssh/id_x_ed25519.pub | ssh x "cat >> .ssh/authorized_keys"

IdentitiesOnly means it will only send that one identity for that one machine (otherwise it will try all of them, like a janitor trying to open a locker with a big keychain of identical keys)

If you always want to use a password to log into a machine, but want to be able to log in in other windows to the same machine without a password:

  Host x
      ...
      ControlMaster auto
      ControlPath ~/.ssh/master-%r@%h:%p

this will multiplex all activity to that host through one tcp connection

you can also use Host * at the beginning of your config to do this for all hosts

to tunnel vnc over ssh to a remote mac(I do this with mac)

  Host foo
        ...
        LocalFoward 5900 localhost:5900


  ssh foo

then locally vnc to localhost:127.0.0.1

I love the multiplexing feature. We have a client who require password, ssh key and MFA. All services are behind a bastion host, which only accepts trafic from select IPs. SSH multiplexing and proxy configuration allows me to enter the password and TOTP just once instead of every time I need to access a service behind the bastion host.

Of course if the multiplex stalls or goes down so do all of the connections you have running through it. It's like screwing up Gnome Terminal or similar that uses a main server and multiple clients. Screw one pooch and you're whole session of things is similarly screwed.

Another annoying "feature" is that opening a new shell with ssh -X will not enable the forwarding if the original master connection was not enabled with it.

True, but I never see SSH go down, unless there's a network issue, in which case I lose all my connections anyway.

Indeed; however, if you have a lingering control file (because an old ssh process was killed, or there was a power failure and it was somehow not removed), it will either refuse to use it, or (occasionally, and I haven't been able to pinpoint when), would just wait there forever.

edit: a typo

Sounds more like a bug than a disadvantage

I have these shell aliases configured, to check and delete the master connections. (Often I end up with stale connections when I have a VPN up, and then just sleep my laptop.)

alias ssh-MasterConnection-check="ssh -O check " alias ssh-MasterConnection-exit="ssh -O exit "

+ then you use them as 'ssh-MasterConnection-check host' etc.

Is there much of an upside to doing the multiplexing on the client side instead of on the server (with something like tmux)?

It seems to me like the session persistence tmux gives would be worthwhile if you have a lot of simultaneous sessions going.

scp and sftp will multiplex too. Remote tab-completion for file transfers also becomes much more approachable this way.

scp remote:~/err[tab] .[enter]

Also, bastion connections get multiplexed as well so connecting to multiple different hosts behind the bastion goes faster.

So you’re saying SCP will tab complete through the control master socket? Neat.

I never saw the value of tmux unless your running a command that can’t be interrupted.

Having multiple windows vs tabs on my desktop seems so much easier.

Yes, I agree. What is the usage for tmux? Multiple tabs on a quake-style dropdown terminal on a desktop (like guake) does seem much easier than tmux, especially when gnu-screen is always available when you need to run an uninteruptible command.

From what I gather, tmux is useful if you are basically running a persistent remote workspace via terminal on a server and treat your desktop like a thin-client, is that correct?

for me this is a common pattern:

  ssh x

then in other windows, I do things like this:

  scp file x:
  ssh x command
  rsync from/ x:to/
  emacs /ssh:x:filename    (this is tramp mode)

edit: one more thing

  ssh x -o BatchMode=yes command

if you have an automatic script to run on a remote machine, adding BatchMode=yes will make it error out instead of stopping and asking for a password

I use a config file for all my regular SSH connections as well. But I stopped using more than one key when I could not think of a threat model that it addressed.

If the bad guys get a copy of my public key off one remote server, they can't use it to access any other remote server. They would need the private key, which is on my laptop.

And if the bad guys get my laptop, then they get all my keys; having separate private keys for separate servers doesn't help if they're all sitting next to each other on one device.

I do set a password on my private key, though.

It leaks information: "we have seen this one pubkey on multiple servers, therefore it's likely to be a key for everything plus the kitchen sink"

If a bad guy gets root on one server you're currently connected via ssh with, and forwarding said key via, they can also access (unless otherwise firewalled) all systems that ssh key grants them access to.

See also: https://github.com/FiloSottile/whoami.filippo.io

Using a private key per system or set of systems means that such an attacker would only gain access to what that key grants them access to.

My "github" key only grants access to my github repos, not to my bitbucket repos or to my DigitalOcean servers, or my Scaleway servers.

I have an SSH key for each "thing", and each key is kept in a different keyring via https://github.com/ccontavalli/ssh-ident, _precisely_ to avoid that problem.

As an example, an attacker gaining root on my Oracle Cloud free server will not be able to clone all my Github repos with it: I only use that key to connect to that server, and while I may have the github key unlocked at the same time - that's on a different keyring which the server has no visibility of.

But if you use agent forwarding with other keys loaded into the agent, how does hat help?

I don't. Each agent gets one key, and that key alone. That's what helps.

https://github.com/ccontavalli/ssh-ident is what I use to manage those agents - one agent per key.

I think the proper solution would be 1) don't use forwarding unless necessary 2) setup touch-to-use on a Yubikey so even with your scenario the attacker couldn't just use the key (it requires touch to be used).

I've (admittedly, conceptual only) a couple problem with this approach I'd love to hear folks' thoughts about, with regards to "touch-to-use".

1. I still have a need to "for s in $list_of_servers; ssh -A $s '..'; done"

How many times do I have to push the button? Is there a setting that allows that "push to allow" for a short while? Great, if so:

2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of?

A solution for this would be to have multiple hardware keys for things I manage: one for $work, one for $personal, another for $github, etc. etc. but then managing them and - especially!! - their SSH agent which may be in memory but relies on the hardware being present, with all issues _that_ entails.... becomes a frigging mess.

So I'm torn... between the simplicity of a hardware key with push-to-allow... and actually being able to _use_ it _securely_.

If I ssh in two different tabs back to back, I still need to touch twice. So it's your case 1 that's not supported nicely. Rather than being insecure.

> Is there a setting that allows that "push to allow" for a short while?

Yes there is. In a newer firmware.

> 2) when I ssh into a system and touch the button to allow it, and the push allowed the use of they key for a short while, am I not in the same problem as before - as the system may be compromised and may be performing other operations I'm unawares of?

Yes but the window of opportunity for the attacker is smaller. Also: it's your setup that requires multiple key operations within short time interval, for some people touching every time is sufficient and most secure.

Seems the ideal solution would be to trigger push-to-allow for signing requests that come in via agent forwarding, but not for local requests. I’ve been thinking about a reliable & secure way to do this. A modified OpenSSH client could enable this pretty easily by simply indicating to the agent where the request originated. But that’d require changes to both OpenSSH and to the agent protocol.

The SSH-agent forwarding model is the problem, I think; Every couple of years someone finds another semi-common scenario where it becomes vulnerable.

I have, since 2010, practiced "jumps" only - that is, if I need to connect to a non-routeable host through a routeable one ("bastion host" or "jump host"), then the intermediate host is only used as a transport, by way of -L/-R forwarding of the final destination's ssh port, or by netcat, or (since a couple of years ago) SSH's internal ProxyJump or ProxyCommand; compared to agent forwarding, this is less efficient CPU-wise and traffic-wise, but not by much; and it is as safe as connecting to the final destination directly, unlike agent forwarding.

That works for bastions, but not other use cases. One common one is pushing & pulling from git on a remote dev box. Or if you want to SCP something between remote machines without having to pull it down locally. Agent forwarding is the best way to do this (outside of possibly generating an ephemeral key pair and copying public keys around for a single use then destroying them... but ain’t nobody gonna do that).

It’s probably the easiest way, but also very vulnerable.

Never seen this use case or anything similar myself. Do you have other examples? I want to broaden my horizons

In general I'd say SSHing from a remote box to another remote box is a non-issue since you can always use some sort of tunneling/bastioning to make that work.

It's when you want to use some other tool that tunnels over SSH -- scp, git, sftp, rsync, etc. -- that you run into trouble.

Consider a remote development instance. So I'm an engineer, and instead of developing on my local I do development on an EC2 instance in AWS (there are a variety of reasons this may be preferential or even required). If I'm pushing & pulling code from GitHub to/from this development instance I'm gonna need to either have a private key on that development instance or have agent forwarding back to my local.

Now suppose I want to copy a large database snapshot between two instances on EC2. There are obvious benefits to being able to transfer directly between these two instances, on the same private network, versus bringing the data to your local (where you might not even have sufficient disk space) and pushing it back up.

Not sure what other use cases exist, but these two alone I think justify the existence of agent forwarding.

SSH agent forwarding does have subtle security issues. But so does putting a private key on a remote server. If you're the only one who has access to the remote server, neither option is problematic. If someone else has root, and you don't trust that person, then both are problematic (and which is worse is debatable).

Thanks. When faced with similar issues, I have always set up an ad-hoc channel (e.g. created a local key, ssh-copy-id it, use it, and remove both the keyfile and the authorized_keys line afterwards). It's more work, but gives exactly the minimum required trust and no more. I've never even considered using agent forwarding for this case.

That said, I don't have to do that often; If I did, I'd probably look for a simpler way (or ignore my paranoia and use ssh agent forwarding...)

Ah. I don't use forwarding so didn't consider that. Thanks.

That multiplex feature is really cool. Is there a way to make it work for pem files? It'll be super useful to specify "-i pem" once and use that for all subsequent ssh/scp. Same goes for the username.

Doesn't ed25519 keys are fixed to 256 in terms of the -b flag, so no need to specify there anything?

Yes. From the ssh-keygen man page:

> Specifies the number of bits in the key to create. For RSA keys, the minimum size is 1024 bits and the default is 2048 bits. Generally, 2048 bits is considered sufficient. DSA keys must be exactly 1024 bits as specified by FIPS 186-2. For ECDSA keys, the -b flag determines the key length by selecting from one of three elliptic curve sizes: 256, 384 or 521 bits. Attempting to use bit lengths other than these three values for ECDSA keys will fail. Ed25519 keys have a fixed length and the -b flag will be ignored.

hey you're right! I have removed '-b 521' from the ssh-keygen command.

     ssh-copy-id -i ~/.ssh/id_x_ed25519.pub x

Thanks for mentioning this - I've been SSH'ing for a long time and never run across it.

Reply on news.ycombinator.com