

SSH key and passwordless login basics for developers - miohtama
http://opensourcehacker.com/2012/10/24/ssh-key-and-passwordless-login-basics-for-developers/

======
apawloski
This was mentioned before, but if this post gains traction it's worth talking
about again:

It is almost totally unnecessary to maintain multiple key pairs for multiple
purposes if they're going to be stored on the same machine (eg separate key
for github). If one of these services is compromised, an adversary will only
get your _public_ key, which is useless. This is very different than the
security practices of symmetric passwords.

~~~
dredmorbius
True.

The better use-cases for separate keys are:

\- Use a key specific to a given client system from which you connect. E.g.:
separate keys for your work and personal machines. If one or the other is
compromised, delete entries for the compromised key in your authorized_key
files.

\- Use shared keys, where necessary, for group infrastructure in a work
setting. Examples might be an AWS login or other systems for which a single
key is permitted (really, such cases should be rare).

\- Use separate keys to make use of forced commands. These keys are single
purpose, and are used to run _a single command_ on a remote host (or set of
hosts). They aren't general-purpose login keys.

------
h2s
The output of "man ssh_config" is popular here lately isn't it? It was on the
front page in a different guise only four days ago.

<http://news.ycombinator.com/item?id=4677049>

~~~
Millennium
It's useful stuff.

What I'd really like to see, though, is a tutorial for using SSH keys from a
thumbdrive in a way that doesn't depend on Gnome or KDE.

~~~
chuppo
ssh doesnt depend on Gnome or KDE, what are you talking about?

These articles are spam. They are collections of snippets from various man
pages and other older resources on the internets. If you think theyre useful,
go back to the study room, youll not advance your skills by expecting
"tutorials" on how to use ssh without kde(!?). Your asking the wrong
questions, and will be led down a fruitless path.

~~~
Millennium
The problem isn't SSH itself, but the tutorials out there tend to assume that
you're using GNOME or KDE (or, more to the point, their automount systems). If
you're not running either one, you're left trying to figure out how to deal
with that problem.

~~~
thaumaturgy
Plug in the flash drive, then "tail -n 20 /var/log/syslog" (on most systems,
and assumes the system isn't very busy), and look for the notification of the
plug-in event with the device node, e.g. /dev/sdb1.

Then, "mount /dev/sdb1 /media/flashdrive", replacing the device node with
whatever you see in syslog, and the mount point with the appropriate folder on
your filesystem (really, whatever you want it to be -- you can mount something
to your home folder if you like). 'mount' should be able to auto-detect the
filesystem on the device unless you're running a really old Linux or BSD.

Does that help?

------
thaumaturgy
Unless I missed something while skimming this, they're suggesting that you set
your password to "something random" and then go on to use ssh keys. This means
that a brute force attack is still feasible (if super incredibly unimaginably
unlikely). Better still is to use, 'passwd -d -l [user]', which will delete
the password (it creates a nonsense hash value, "" I think) and then lock it.

While you're messing about with config files, make sure that "PermitRootLogin"
in /etc/ssh/sshd_config is set to "no" (this is now default in most
distributions I think), and also add an "AllowUsers [user] [other user] [...]"
line thereabouts, which will help to protect you from misbehaving packages or
someone attempting to add remote users to your system without your permission.

It should go without saying that if you do all this, and you somehow lose your
private key, and you don't have a good backup as the article suggests (for
whatever reason), and you don't have some kind of local console access, then
you're pooched. Private key management is easy to screw up, so don't scoff.
Make sure you have some other way of accessing your machine if you can't get
to your private key.

~~~
h2s

        > Better still is to use, 'passwd -d -l [user]',
        > which will delete the password and then lock it.
    

Better yet, set PasswordAuthentication to "no"

~~~
thaumaturgy
How is that better?

~~~
qznc
It instantly applies for all users. "passwd -d" must be done for each user,
which means you might forget it sometimes.

~~~
pilif
OTOH, passwd -d also disables console login while disabling password
authentication in the ssh config obviously doesn't.

~~~
npsimons
If they can get to your console, you've already lost. And I know it might be
OT to put it in this subthread, but just to bin up some of my responses:

\- Yes, this is a repost, and yes, I had a similar reaction to many of "people
_still_ don't know about this?!", but if someone comes away using SSH with
keys after reading this article, then it's worth it. It'd be nice if every
programmer out there had some sys admin experience, but it's not going to
happen.

\- SSH keys depends on KDE or GNOME? That ought to surprise the Windows and
Mac users (not to mention all those BSD/Linux/UNIX users who don't use KDE or
GNOME) who use SSH keys. Last I checked (last time I logged into a freshly
booted system), you ran ssh-add on first login, and if that doesn't work (or
you have to do it for each shell/session), check the man page for keychain[1].

[1] - <http://www.funtoo.org/wiki/Keychain>

------
bcl
passwordless sudo access to root? Not a great idea. If you don't like typing
your sudo password so often just change the timeout.

I'd also suggest using ssh-add -t <timeout> to limit the lifetime of your ssh
keys in the agent.

~~~
dredmorbius
There's also a PAM module that will forward sudo authentication requests over
your SSH authentication socket.

~~~
miohtama
Have you more details? I tried to find this kind of module but no dice.

------
joshstrange
For setting up a remote computer for SSH key login I use this little snippet
that I think I found on HN not too long ago

    
    
        cat ~/.ssh/id_rsa.pub | ssh USER@HOST "cat >> .ssh/authorized_keys"
    

Of course the receiving server mush have a ".ssh" folder in the user folder
and "authorized_keys" must exist "touch ~/.ssh/authorized_keys" but it is a
super easy way to add your key to the remote server. Just thought I would
share, I hope someone else finds it useful.

~~~
viraptor
New openssh already has this covered in a more standardised way:

    
    
        ssh-copy-id USER@HOST

------
jackalope
Agent forwarding is tremendously useful, but you should not forward your agent
to systems you don't control or can't trust. If you do, you risk having your
agent hijacked and used to connect to any system where you have public key
authentication enabled.

The author implies that you need to enable agent forwarding to do a git pull
from GitHub, but that would be incredibly dangerous. This can't possibly be
true, can it? If so, you might as well hand them your private key and
passphrase.

~~~
munificence
From the ssh man page:

Agent forwarding should be enabled with caution. Users with the ability to
bypass file permissions on the remote host (for the agent’s UNIX-domain
socket) can access the local agent through the forwarded connection. An
attacker cannot obtain key material from the agent, however they can perform
operations on the keys that enable them to authenticate using the identities
loaded into the agent.

~~~
jackalope
Sorry, I didn't mean to suggest that they could obtain the key, just that
hijacking the agent was equally dangerous (provided they know where to use
it).

------
ericcholis
I know there are a thousand tutorials on each of these topics, but it's nice
to have them all in one place.

------
djhworld
I'm a java developer and most of my colleagues have no idea how this stuff
works, or even use it themselves. I've had to explain these concepts to my
peers many times

------
danielwozniak
Instead of password-less sudo you can use `sudo -s` to get a root shell. `sudo
-sE` for a root shell but preserve your user's environment variable.

------
mattdeboard
Saved this and passed to my programmer co-workers. It seems to be a very rare
commodity to understand this topic where I live.

~~~
miohtama
Nice that you find this useful :)

