Set up remote access in UNIX through OpenSSH (developerWorks) [LWN.net]

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 16, 2007 23:26 UTC (Fri) by ldarby (guest, #41318) [Link]

While I applaud IBM for advocating OpenSSH over eg. rsh or telnet, they missed a couple of points.

1. To avoid typing in the passphrase each time, he uses a blank passphrase which is horribly insecure. To avoid that, use ssh-agent which holds your keys for you, and is slightly more secure.

2. To copy your identity to a new machine, there is already ssh-copy-id, there's no need to go and re-implement it.

Ok, to be honest I found out about these 2 points about 6 years after I first started using ssh, I just want everyone to be aware of them...

ssh-copy-id

Posted Feb 17, 2007 4:52 UTC (Sat) by socket (subscriber, #43) [Link]

Thanks! I just learned about ssh-copy-id. Much appreciated. :)

ssh-copy-id

Posted Aug 9, 2007 16:39 UTC (Thu) by tom123 (guest, #46685) [Link]

yeah, me too :) --Tom

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 17, 2007 6:12 UTC (Sat) by k8to (subscriber, #15413) [Link]

While ssh-agent is a great solution for a lot of purposes, it's often not good enough for automation tasks.

Automation often requires that the automated task will continue to work after a reboot or similar, and thus ssh-agent will only work if you store the passphrase on-disk, in a script, etc. It is likely that this is security-equivalent to a blank passphrase, as the key-file is locally-stored and encrypted anyway. I think a blank passphrase is appropriate in some cases. You do gain limited advantages in security over an unencrypted, unauthenticated link, and the blank passphrase reminds you of the limitations.

Certainly you need to consider whether ssh-agent OR blank passphrases are acceptable security risks in your environment.

Thanks for ssh-copy-id. I never knew.

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 17, 2007 22:51 UTC (Sat) by rasjidw (subscriber, #15913) [Link]

If using a blank passphrase for remote automated administrative functions, one can also use the command="command" option in the authorized_keys file to enforce that the given key is only used to run that command, and no other. See man sshd for details.

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 19, 2007 20:36 UTC (Mon) by dtucker (subscriber, #6575) [Link]

> use the command="command" option in the authorized_keys file

You can also use the "from=" key option to restrict where the key can be used from. This makes a stolen key less useful as you need to spoof the source address too; depending on your network this can be anywhere between only a bit more difficult (if you own a box on the same subnet as the real source) to impossible (if you're on the other side of a firewall with strong anti-spoofing policies).

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 19, 2007 8:55 UTC (Mon) by busybits (guest, #43397) [Link]

Automation tasks made with expect scripts work no matter if you reboot or not. You can use them for both ssh and scp. --Ann

Set up remote access in UNIX through OpenSSH (developerWorks)

Posted Feb 19, 2007 21:39 UTC (Mon) by muwlgr (guest, #35359) [Link]

They work, as everything else, either with passphrase-less keys, or with passphrase stored somewhere in clear or decipherable format.

Host authenticity check

Posted Feb 16, 2007 23:55 UTC (Fri) by ldo (subscriber, #40946) [Link]

The article mentions the "authenticity of host <blah> can't be established" warning, but implies that you simply have to put up with it the first time you connect to a new host.

In fact, ignoring this warning and typing "yes" to proceed leaves you open to the chance of a host-spoofing attack. The right way to deal with this is one of:

You (or somebody) previously did the following command on that host:
ssh-keygen -l -f /etc/ssh/ssh_host_key.pub
and saved the output so you can compare the host key fingerprint with that from the warning, to ensure they're the same. Or,
You previously grabbed a copy of the entire /etc/ssh/ssh_host_key.pub file, so you can manually insert it into your ~/.ssh/known_hosts file and avoid the warning altogether.

The article says you will get another "warning" if the host key changes. In fact, in the default SSH configuration, this is not a warning, this is an error, and it will not let you connect to the host. This is a Good Thing, as there should never be any reason for the host key to change. (When I install a new Linux version on a machine, one of the things I'm careful to save from the old configuration is the SSH host key.)

Host authenticity check

Posted Feb 17, 2007 6:18 UTC (Sat) by k8to (subscriber, #15413) [Link]

To be honest, I get these warnings in all sorts of normal situations, and I'm not sure how it can be reasonably addressed.

Recently I went through a process of evaluating various unix variants on my new AMD64 system. Other systems connecting to it received warning after warning as each install generated a new host key without asking me. Sure I could (theoretically) transfer the key from one system to the next, if they could read each other's filesystems, or whatever. Realistically neh.

Disaster recovery frequently changes the host keys.

Operating system upgrades typically result in host key changes.

Referring to the same computer by different names results in a different but similar warning. Worse, when one of the names is really a service name, and ssh seems to have (perhaps cannot have) any provision for recognizing this, resulting in a series of warnings in different scenarios.

The long and the short of it is that most administrators seem to view the entire class of warnings as crying wolf, and ignore them. You may think these admins are all sloppy, but I claim that the sum of the above issues means this result is basically inevitable in all but the most controlled of conditions. I basically notice the message, think about whether there is a reaonable explanation, and if so I ignore it. If there is not a reasonable explanation then I investigate.

Host authenticity check

Posted Feb 17, 2007 16:15 UTC (Sat) by jreiser (subscriber, #11027) [Link]

Ssh can trigger the unknown host check when connecting to a system that is running from a "live CD-ROM." Such a system generates a new host key upon each boot. The associated mechanisms for keeping persistent state across boots often target the individual user and not the host id.

Host authenticity check

Posted Feb 18, 2007 14:29 UTC (Sun) by juriise (subscriber, #38305) [Link]

>Referring to the same computer by different names results in a different
>but similar warning. Worse, when one of the names is really a service
>name, and ssh seems to have (perhaps cannot have) any provision for
>recognizing this, resulting in a series of warnings in different
>scenarios.

These two servers are acccessed through the same ip using destination nat. With the HostKeyAlias, ssh cheks the host key without beeing confused.

host egg
  hostname www.xxx.net
  User riise
  HostKeyAlias egg-axx
  CheckHostIp no
host morr
  hostname www.xxx.net
  User riise
  port 10022
  HostKeyAlias morr-axx
  CheckHostIp no

Port numbers in known_hosts

Posted Feb 19, 2007 8:46 UTC (Mon) by dtucker (subscriber, #6575) [Link]

Starting in 4.4, OpenSSH will also record the port number against the host key when you use a non-standard port so you don't actually need the hostkeyalias. When this happens you will see entries like this in your known_hosts file:

[1.2.3.4]:222 ssh-rsa AA...

It doesn't happen if you set HostKeyAlias and it transparently falls back to the non-port-specific one if need be, so most folks probably haven't noticed.