[NBLUG/talk] I'm getting ssh scanned! Should I be worried?

[troy]

On Sat, Oct 23, 2004 at 08:00:34AM -0700, Dave Sisley wrote:
> Thanks, Augie!
> 
> Hmmm... I'm confused (obviously).  Since the goal is to be able to log
> into my home box from a few trusted machines, I thought I needed to
> generate key pairs on each of those machines and provide the public
> key from the remote machines to my home machine.  This is done by
> appending the remote machine's public key to my home box's
> authorized_keys2 file.

I'm going to be verbose and probably repeat things that have already
been written, but I hope that having it all in one place will be
helpful.

As you've probably gathered by now, it does not matter which machine
generates your public and private user (as opposed to host) keys.  You
can move them around to various other machines and they'll work fine.
The machine you're coming from must have the private key and the machine
you're logging into must have the corresponding public key.  If the keys
are locked with a passphrase (recommended!) then you must know it.  If
you're trying to log in with a password then PasswordAuthentication=Yes
must be set in the remote hosts' sshd_config.

What you *must not do* however, is keep (and more imporantly, use) an
important private key on any machine that you do not trust.  If that
untrusted host is compromised, the attacker can install key loggers or
trojaned ssh binaries or whatever their evil mind can conceive of.  The
fact the connection is encrypted matters not if the attacker can grab
your passphrase or account password as you type it into a compromised
binary.  If the keypair does not have a passphrase, then obviously
access will be granted simply by their possession of the private key.

I can log into an untrusted machine safely from home because nothing
sensitive is ever transferred -- I've already unlocked my private key
with my passphrase from the safety of my (hopefully) secured
home workstation.

> > Frank is absolutely right; do not ssh from un-trusted machines, and
> > do not keep your private keys on un-trusted machines.
> > 
> 
> I'm not sure what you mean here.  I should consider the sonic account
> to be un-trusted?  As for not keeping my private keys on an un-trusted
> machine, do you mean the private key from my home box (because that
> makes sense - that private key stays on that machine).  Or do you mean
> I should not keep the private key generated on the sonic machine on
> the sonic machine?  In which case, how do I log into my home box from
> there?
> 
> - Or is the larger point that I should not be logging in via sonic?

Yes.  Don't log into any other machines from a public shell server.
Don't type in a password or passphrase from there.  I mean it's kinda
fun to tunnel all over the Internet from the various machines at which
you have access, but in reality, if you're logged into shell.sonic.net
then you may as well log directly into your home computer from wherever
you are.  (Assuming that is a safe place!)

I've heard it suggested that (if you use an ssh-agent), you could
forward the agent connection via ssh -A, but that's not a good idea
either:
>From man ssh:

	 -A
	Enables forwarding of the authentication agent connection.  This can
	also be specified on a per-host basis in a configuration file.

	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.

> I made another attempt to change the port number, and I can log into
> the home box from my laptop with the new port number, but I can't from
> outside via my sonic account.  Here is the verbose output from the
> sonic terminal (with certain details mangled becase I am paranoid).
> 
> 
> $ ssh -v -p 12345 me at my.home.machine
> ssh: connect to address <ip address> port 12345: Connection refused

Try:
$ telnet my.home.machine 12345

Bet you get a connection refused also.  It looks like that port is just
not open to the outside world.

(telnet is a great tool to see what is listening (or not listening) on a
given port)

<http://www.ibiblio.org/ais/siberia.htm>


-troy