ssh offers without question all your keys to any server

Bug #505493 reported by LimCore
258
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openssh (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

If you connect to some ssh, then without question ssh seems to happily offer all of your private keys, therefore informing the target server about how many / which keys you have.

This is a privacy breach, consider:

you have a general key, you have a key used for very important work sever (id_rsa_ubuntu_repo.pub), and you have key used for fun/testing (id_rsa_tests.pub).

You connect to some game ssh server, or IRC shell or some testing VPS, and on connection you inform that server that you also have key which name indicates that you have very important key.

User might not want to give away this information on connecting.

Solution: do not add any keys by default, or ask before offering them;
Or at least offer only the default key if it exists.

When applying this privacy fix, please remember to add warning message informing users how to do ssh-add now (because of change in behaviour), unless it will be interactive question.

ProblemType: Bug
Architecture: amd64
Date: Sun Jan 10 15:05:37 2010
DistroRelease: Ubuntu 9.10
NonfreeKernelModules: nvidia
Package: ssh (not installed)
ProcEnviron:
 LANGUAGE=
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: openssh
Uname: Linux 2.6.31-17-generic x86_64

Revision history for this message
LimCore (limcore) wrote :
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Thank you for using Ubuntu and taking the time to report a bug.

I'm afraid I don't understand the problem as described. For the SSH protocol, http://www.ietf.org/rfc/rfc4251.txt has details on the protocol architecture and http://www.ietf.org/rfc/rfc4252.txt specifically on the authenticaion protocol.

For the openssh implementation, openssh should only offer ~/.ssh/id_rsa or ~/.ssh/id_dsa by default, unless you have configured ssh differently (see man 1 ssh) . Even if it did offer multiple keys, it would be multiple public keys that should give no indication of their use (therefore useless to an attacker).

Can you explain the problem with more detail including steps to reproduce? Thanks

Changed in openssh (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Incomplete
Revision history for this message
LimCore (limcore) wrote :

Jamie: in short: if you send all your ssh public keys, then their act as sort of fingerprint that can identify you.
If use use key A for work and B for games, but you same both keys A,B when connecting to either server, then if the servers share administrative stuff, then they will know it's the same person.

It can be seen as a privacy problem, for example if you do not want to advertise to every ssh server (game server, irc shell etc) that you also have a public key of an Ubuntu developer.

Longer example

When user have multiply priv+pub keys, in example:
~/.ssh/id_rsa
~/.ssh/id_rsa_work
~/.ssh/id_rsa_games

and I connect to a game server via ssh,

Then I do not necessarily want to inform the game's server that I also have given public ssh key for work, because this public key used for work can be recognized (in example if it would happen that same person that operates game server also is admin at my work place).

If I understood correctly, the game server will receive list of all 3 of my public keys, and looking at them, it can be possible to realize that this is the same client.

Revision history for this message
LimCore (limcore) wrote :

Sorry, typos.

Jamie: in short: if you send all your ssh public keys, then they act as sort of fingerprint that can identify you.
If use use key A for work and B for games, but you use same both keys A,B when connecting to either server, then if the servers share administrative stuff, then they will know it's the same person.

visibility: private → public
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

As I understand this bug, I think the vulnerability is a bit convoluted and is not something we should try to address in Ubuntu without upstream. If you feel strongly about this issue, I encourage you to file a bug with upstream OpenSSH.

Changed in openssh (Ubuntu):
assignee: Jamie Strandboge (jdstrand) → nobody
status: Incomplete → Won't Fix
To post a comment you must log in.
This report contains Public Security information  
Everyone can see this security related information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.