secure log

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
When someone attempts to ssh into my machine, in /var/log/secure I can
see the username the attacker is trying to use...I would like to be
able to see the invalid passwords as well.  Can anyone help me out
with that.  Thanks

Re: secure log

Quoted text here. Click to load it

This is actually a big security hole, as you will see all the
unintentional typos your legitimate users make.

What do you hope to accomplish seeing these passwords?


(try just my userid to email me)
see X- headers for PGP signature information

Re: secure log

On Feb 14, 11:05 pm, Keith Keller <kkeller-use...@wombat.san-> wrote:
Quoted text here. Click to load it

I'm the only user on this machine....and to be able to view /var/log/
secure one needs root privileges so I'm not too concerned about other
users seeing mistyped passwords in that log or anything like that.
What I would like to know is if the passwords being used for invalid
ssh attempts to my machine (by "hackers") are my actual passwords I
use with for online purposes (email, banking, etc).  I don't care if
invalid users try to ssh into my machine, but if those invalid users
use MY VALID PASSWORDS then its a different story

Re: secure log

On Thu, 14 Feb 2008, in the Usenet newsgroup, in article wrote:

NOTE: Posting from (or some web-forums) dramatically
reduces the chance of your post being seen.  Find a real news server.

Quoted text here. Click to load it

The only way you'll see those is to decode the SSH login data stream (no
easy task) unless you're seeing their attempts as raw text (try using a
packet sniffer), OR by going in and altering the SSH login binary which
would be a major security hole even if you are the only one on the system.

Using "other passwords".  Isn't it a sign of the times that every
freakin' electronic service (banking is wonderful that way) insist that
you have to use "our new secure service".  From the people who brought you
four digit "PIN" numbers as a security feature.  Yeah, right.

There is a huge repository of guidance material related to creating safe
authentication schemes.  I'm sure everyone has told you the "not a word in
a dictionary", "mixed case", include punctuation character", yada-yada
rules - perhaps thousands of times.  Passwords should not have a connection
to the user name or individual. That means using your mother's telephone
number is out, as is the vehicle license plate number, the name of your
moose, or your favorite sports team.   That's all great, but how do you
come up with unique passwords for each account/service that you have?  In
the past, people used a single password (bad - compromised once is the same
as compromised everywhere), or a primary part with suffixes for each (as in
"passkeyBaNk" and "passkeyPr0n", and so on - marginally better, but still
pretty vulnerable).

A suggestion is to use pass-phrases created by taking the first or second
letter out of each word of a phrase - the classic example being "TtL*,h1WwUr"
(from the nursery rhyme "Twinkle, Twinkle, Little Star...").  Because these
_phrases_ have to be memorable TO YOU (but not the actual characters that
make up the passphrase you key in), you can "personalize" them into some
memorable part - such as "Bank Of Podunk Sucks Black Holes Through Cocktail
Straws" (and simply not include the identifying part - "sBhTcs"  is the
idea). You can then make unique passwords for each service, and while the
actual "password" is totally meaningless, it's easy to "remember" and
there is thus no need to have passwords "saved" or "remembered" in a
vulnerable manner.

Quoted text here. Click to load it

Only that you are keeping your passphrases in an unsafe manner. Let's
think about that for a moment.  First rule - have "good" passwords (yeah,
that's given).  Second rule - DO NOT WRITE THEM DOWN in any way that they
can be seen (OK, no sticky notes taped to the back of the keyboard). Third
rule - independent passwords used only for one service (as above). Fourth
rule - change/expire/replace them on a suitable timescale, and that means
having available "replacement" passwords than can be used RIGHT NOW if
needed. Fifth rule - be careful WHERE you use your password protected
services. If you want to check your banking/mail/pr0n/bookie from an
insecure computer or network, be aware that your authentication may be
sniffed.  Your call.

        Old guy

Re: secure log


Instead of trying to figure out what passwords they are using, you
could change your authentication on ssh to pubkey/privatekey, plus
password.  This would give you two factors of authentication, one the
"attacker" would have to have your public key and private key in order
to get into your box.  If you can set it up to also use a password
after this they would then have to guess your password as well.

If you take the tips given from Moe Trin on strong passwords, you have
doubled your protection.

Another option to add is to use iptables to restrict IPs that can log
into your box.  By restricting by IPs, "attackers" can not get to your
box without knowing your allowed IPs and spoofing them.

In my humble opinion I don't think you should try to look at the
passwords, just beef up your security and access to ssh.

Re: secure log

ibuprofin@painkiller.example.tld (Moe Trin) writes:

Quoted text here. Click to load it

I did this years ago, and it hasn't been bothered since. The vast
majority of ssh attacks use automated scripts/malware, or are run by
script-kiddies. Trying to attack a service with "secure" in the name
seems almost self-defeating, when you think about it...

 [** America, the police state **]
Whoooose! What's that noise? Why, it's US citizen's
rights, going down the toilet with Bush flushing. /

Re: secure log


well - if you want to hack around - you can always (if you have root
access which I assume you do) write a few lines of perl and parse the
output of the following strace which DO include the cleartext
     strace -fq -e trace=read,open -o /tmp/skit.out -p <PID OF SSHD>

Not nice, but a possibility. I'm not here to tell you if I'd do the
same or not, only that it's possible.

Quoted text here. Click to load it

Re: secure log

On Thu, 14 Feb 2008 19:47:49 -0800 (PST),

Quoted text here. Click to load it

Doesn't it just torque you to ask a  legitimate question and get
advice rather than an answer...

The answer is, you tweak the source code yourself.  There is no other
way other than perhaps to run Wireshark / Tshark and constantly montor
your SSH port (probably 22) to a ring buffer.  I suspect you'll see an
encrypted password that won't do you any good.  And spend a lot of
computer resources to run 'shark while you're looking.

Everybody else has told you why this is a "tweak the source, Luke", so
I won't belabor that.

If you do alter the SSH daemon, be sure you keep a copy of the
unaltered executable in a place that you can instantly revert from and
that you know how to revert (stop the modified, start the original).

Site Timeline