|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|
ssh and trust (Was: Re: [PLUG] Putty and firewall piercing)
|
In the message dated: Wed, 28 Feb 2007 08:21:35 EST,
The pithy ruminations from Art Alexion on
<Re: [PLUG] Putty and firewall piercing> were:
=>
=> On Tuesday 27 February 2007 20:50, Stephen Gran wrote:
=> > On Tue, Feb 27, 2007 at 07:47:16PM -0500, jeff said:
=> > > What is the (relatively) safest way to access one's home box from the
=> > > Outside World? Is SSH safe enough (with nonstandard port and secure
=> > > password)?
=> >
=> > SSH with key based authentication, and disabled password authentication is
=> > best. Good passwords are a good runner up, though.
=>
=> As a practical matter, if the client computer is your employer's or some other
=> shared computer, wouldn't a good password be better that keeping your key on
=> the insecure client?
=>
Perhaps there's some confusion about SSH keys, passwords, and passphrases.
At a high level, here are the elements involved:
ssh password
sort of like telnet, although everything is encrypted
you enter a password for each login. Not recommended on
shared or untrusted machines.
ssh key
the remote server is configured to allow logins based on
the key sent to it. the key is stored on the local machine
(which, as Art points out, may be untrusted)
ssh passphrase
the key, stored on the local machine, may be protected by
a passphrase (which can be much stronger than a password).
Typically, the passphrase is not stored on the client machine.
Aside from some special functions (ie., daemon accounts, where
ssh communication is used for specific functions, restricted by
the remote server), I never recommend ssh keys without a complex
passphrase.
ssh-agent
a software daemon that caches your passphrase, supplying it
to the local ssh client, in order to decrypt your stored keys
on demand and submit them to the remote ssh server to complete
the connection. Never recommended on shared or untrusted
machines.
ssh + OTP
ssh plus a mechnism like OPIE or S/KEY that uses one-time
passwords
If the local machine is trusted, then a requiring an ssh key on the remote
machine (and prohibiting passwords) is the easiest and most secure option.
If there's a doubt about the local machine, that risk should be examined, in
order to determine the appropriate response.
In Art's question, the local machine is owned by an employer. This is fairly
common. Assuming that the local machine has not been compromised, is run
securely, and that you "trust" the admins who are running the machine, there's
still a risk in that the employer has a right to the data (ie., your ssh key)
stored on that machine. However, _if_ the ssh key was created with a
passphrase, that key is useless without the passphrase.
The worst situation is that the ssh key has been created without a passphrase
(or that the key was created on the untrusted machine, and the passphrase was
sniffed when the key was created). In this situation, anyone with access to the
key (and sniffed passphrase, if one was used) also has access to your remote
server. Remember, the ssh key is protected with the standard filesystem ACLs.
How much do you trust the local admins (and how backup tapes are stored)?
The second case to examine is that of an untrusted local machine. This may be a
box in a cyber cafe, a hostile employer, etc. In this case, you can't trust
that the machine or ssh binaries have not been compromised, either by outsiders
(hackers), or by the owners of the machine. For example, the ssh binaries may
have been modified to capture and report passwords and passphrases. Similarly,
if the machine was compromised, or if the owner is deliberately snooping, the
kernel memory could be monitored for the same passwords and passphrases.
In this case, the most secure method for using ssh from this host to connect to
your remote machine is to use one-time passwords. The one-time password MUST be
computed separately from the untrusted environment. This may mean using a PDA
to generate the OTP or pre-generating a printed list of OTPs.
In this scenario, ssh is used as an method for encrypting the data
transmission, while the OTP protocol is used for authentication. This scenario
still has the worst-case potential that the Bad Guys have compromised ssh to
the extent that all traffic is available in the clear. However, the use of
one-time passwords ensures that they cannot access the remote server in the
future.
Of course, this just protects your login access. If you do the following:
[insecure.machine]% ssh myserver.example
OTP login
[myserver.example]% su -
enter root password to myserver.example
[myserver.example]#
and someone's mucked with ssh on insecure.machine, then you've just given them
the root password to myserver.example.
Other things to consider...MITM attacks against OTP are possible. An even
greater concern may be session hijacking, once the encryption and authentication
are complete. Personally, I consider both of these risks to be very small, given
that there are many targets that offer a higher return. In the typical
"cyber-cafe" setting, I consider the web browser and simple password sniffing
from the keyboard to be much, much greater concerns than OTP MITM or session
hijacking attacks.
As with everything about security, the procedure and technology you choose
should be appropriate for the perceived value and risk.
For example, I won't access to my on-line banking service from a cyber-cafe
anywhere, ever. I will use the ssh client (or Mindterm) running on the
virus and spyware-laden Windows machine at a cyber-cafe to access my ISP shell
account, but only via a OTP that's computed off-line (on my PDA).
In this scenario, the value of my bank account is greater than the value of my
FreeBSD shell account. I perceive the risk that there's software running on the
cyber-cafe machine to sniff passwords during my SSL web browsing to be much
greater than the risk of software that's designed to break S/Key.
Mark
=>
=> _____________________________________________________________
=> Art Alexion
=>
=> PGP fingerprint: 52A4 B10C AA73 096F A661 92D2 3B65 8EAC ACC5 BA7A
=> Keyserver: hkp://subkeys.pgp.net
=> The attachment - signature.asc - is my electronic signature; no need for
=> alarm. Info @
=> http://mysite.verizon.net/art.alexion/encryption/signature.asc.what.html
=> _____________________________________________________________
=>
=> --nextPart2077001.AqrXI6DbEq
=> Content-Type: application/pgp-signature
=>
=> -----BEGIN PGP SIGNATURE-----
=> Version: GnuPG v1.4.2.2 (GNU/Linux)
=>
=> iQCVAwUAReWB7ULG/oYII0YuAQLQZQQAvncplmNSrNZraNw2LQJEsfzlYp0RV90b
=> V9RQ3si7zvHe144fbtuaQSB67CSXPbTsD/Nj9wneYFgPW/tOiriJ4K9FOb22N8eM
=> pNulPpVu6TuAyR4A69ZsDTwIpkaOvZIVFAuENMcGI0mEDHSHCt6dN0n7td97XQto
=> /rtx0DTBqo4=
=> =F7eS
=> -----END PGP SIGNATURE-----
=>
-----
Mark Bergman Biker, Rock Climber, Unix mechanic, IATSE #1 Stagehand
http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40merctech.com
I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman
___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|