ssh gives "Permission denied, please try again"
Anthony Campbell
forth, without problems. I can also ssh to localhost without problems.
But I can't ssh to a...@acampbell.org.uk. I get "Permission denied, please
try again", and at the third attempt I get "Permission denied,
publickey,password)".
I'm trying this because I shall be going abroad later and want to ssh to
my machine at home to read mail.
Googling shows a number of people with similar problems but no solutions
for me. Some suggest changing the permissions of /dev/tty*, but I'm
reluctant to do this and in any case the changes would not survive a
reboot.
Any suggestions please?
--
Anthony Campbell - a...@acampbell.org.uk
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews,
and sceptical articles)
Ian Rawlings
> I have 3 machines on my home network and I can ssh to them, back and
> forth, without problems. I can also ssh to localhost without problems.
> But I can't ssh to a...@acampbell.org.uk. I get "Permission denied, please
> try again", and at the third attempt I get "Permission denied,
> publickey,password)".
Well, first thing to do is to log into acampbell.org.uk and stop the
SSH listener daemon then run it from the command line as "sshd -d",
then log in again with ssh -v to see what it says at both ends.
That'll give you more info to use to figure out the problem.
However as for us helping out, we have no idea what acampbell.org uk
is, is it a machine on your home network? And are you sshing to
acampbell.org.uk from outside or inside, and if so, what IP address is
it ending up on, e.g. are you actually trying to ssh into a router
rather than what you think you are, and so on.
Running sshd -d should clear up a lot of confusion for you though.
--
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/
Anthony Campbell
> On 2008-07-17, Anthony Campbell <a...@acampbell.org.uk> wrote:
>
>> I have 3 machines on my home network and I can ssh to them, back and
>> forth, without problems. I can also ssh to localhost without problems.
>> But I can't ssh to a...@acampbell.org.uk. I get "Permission denied, please
>> try again", and at the third attempt I get "Permission denied,
>> publickey,password)".
>
> Well, first thing to do is to log into acampbell.org.uk and stop the
> SSH listener daemon then run it from the command line as "sshd -d",
> then log in again with ssh -v to see what it says at both ends.
> That'll give you more info to use to figure out the problem.
>
> However as for us helping out, we have no idea what acampbell.org uk
> is, is it a machine on your home network? And are you sshing to
> acampbell.org.uk from outside or inside, and if so, what IP address is
> it ending up on, e.g. are you actually trying to ssh into a router
> rather than what you think you are, and so on.
>
> Running sshd -d should clear up a lot of confusion for you though.
>
acampbe..org.uk is my domain name so I supposed I had to use
a...@acampbell.org.uk to log in. The machine in question is called
arcadia.
Here are the outputs of what you requested:
arcadia:~:$ sudo /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.7p1 Debian-12
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-1024
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
arcadia:~:$ ssh -v a...@acampbell.org.uk
OpenSSH_4.7p1 Debian-12, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to acampbell.org.uk [82.165.58.181] port 22.
debug1: Connection established.
debug1: identity file /home/ac/.ssh/identity type -1
debug1: identity file /home/ac/.ssh/id_rsa type 1
debug1: identity file /home/ac/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7
debug1: match: OpenSSH_4.7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.7p1 Debian-12
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'acampbell.org.uk' is known and matches the DSA host key.
debug1: Found key in /home/ac/.ssh/known_hosts:7
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/ac/.ssh/identity
debug1: Offering public key: /home/ac/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/ac/.ssh/id_dsa
debug1: Next authentication method: password
a...@acampbell.org.uk's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
This is where things stop.
Anthony
Ian Rawlings
> debug1: Bind to port 22 on 0.0.0.0.
> Server listening on 0.0.0.0 port 22.
That just shows the server starting up, when you logged in via ssh to
test, it should have spat out a whole load more information, which
would have included the reason why it refused your login.
> debug1: Authentications that can continue: publickey,password
> debug1: Next authentication method: publickey
> debug1: Trying private key: /home/ac/.ssh/identity
> debug1: Offering public key: /home/ac/.ssh/id_rsa
> debug1: Authentications that can continue: publickey,password
> debug1: Trying private key: /home/ac/.ssh/id_dsa
> debug1: Next authentication method: password
> a...@acampbell.org.uk's password:
> debug1: Authentications that can continue: publickey,password
> Permission denied, please try again.
Well, it looks like it's gone OK other than you not supplying a
matching private key for the public key in the remote target account,
and if you supplied the right password then it looks like maybe PAM
login is enabled via SSH and it's throwing you out. Try editing out
PAM login in the sshd config file but first of all, re-do the sshd -d
and check the output it produces as you do your test ssh login. If it
does not output anything more, then you're not logging into what you
think you are!
Also make sure that the contents of id_dsa.pub or whatever you've
called your public key is in the authorized_keys2 file in the .ssh dir
in the home directory of the target account. Finally, make sure the
.ssh directory in that account is chmod 700 and the files inside it
are chmod 600.
Anthony Campbell
> Also make sure that the contents of id_dsa.pub or whatever you've
> called your public key is in the authorized_keys2 file in the .ssh dir
> in the home directory of the target account. Finally, make sure the
> .ssh directory in that account is chmod 700 and the files inside it
> are chmod 600.
>
I'd already tried turning off PAM. I didn't have any authorized_keys
file. I also don't have id_dsa.pub; only id_rsa.pub. I copied this to
authorized_keys but no result.
Ian Rawlings
> It doesn't change when I try to login. This isn't good?
Indeed, if the sshd daemon doesn't show a string of debug statements
then exit when you log in after putting it into debug mode, then
you're not connecting to that sshd daemon. This means you're either
trying the debug daemon on the wrong host, or there's two sshd daemons
with different configs running on the same box.
You need to stop the sshd service on the box you are trying to log
into, then run the daemon itself with "sshd -d" which should give you
similar output to what you got before, but when you ssh to that box
the sshd debug daemon should output a load more stuff then quit,
leaving you connected from your source machine. If you're not getting
that, then you have some confusion over where you are connecting to,
i.e. the machine you think you are connecting to isn't the one that
you are connecting to. Check the /var/log/ files (e.g. messages) on
your machines for sshd entries, you should see them for logins and
login attempts.
> I'd already tried turning off PAM. I didn't have any authorized_keys
> file. I also don't have id_dsa.pub; only id_rsa.pub. I copied this to
> authorized_keys but no result.
You might want to try authorized_keys2 instead, although first of all
you need to figure out where you are sshing into!
Ian
> arcadia:~:$ ssh -v a...@acampbell.org.uk
> OpenSSH_4.7p1 Debian-12, OpenSSL 0.9.8g 19 Oct 2007
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: Applying options for *
> debug1: Connecting to acampbell.org.uk [82.165.58.181] port 22.
That's the address of kundenserver.de. Since your domain is registered
with Schlund in Germany, I am wondering what exactly you are
connecting too. "Customer server" does not sound like your desktop
machine: it sound like something at Schlund.
Ian
Anthony Campbell
>
>> It doesn't change when I try to login. This isn't good?
>
> Indeed, if the sshd daemon doesn't show a string of debug statements
> then exit when you log in after putting it into debug mode, then
> you're not connecting to that sshd daemon. This means you're either
> trying the debug daemon on the wrong host, or there's two sshd daemons
> with different configs running on the same box.
>
Thanks for these clarifications. There are not two daemons running so
the problem must be with the host I'm trying to connect to.
I thought the right host to connect to would be a...@acampbell.org.uk
since that is what I use for emails etc. I can connect to
arcadia.acampbell.org.uk but that wouldn't work from a computer outside
my newtwork, or would it?
> You need to stop the sshd service on the box you are trying to log
> into, then run the daemon itself with "sshd -d" which should give you
> similar output to what you got before, but when you ssh to that box
> the sshd debug daemon should output a load more stuff then quit,
> leaving you connected from your source machine. If you're not getting
> that, then you have some confusion over where you are connecting to,
> i.e. the machine you think you are connecting to isn't the one that
> you are connecting to. Check the /var/log/ files (e.g. messages) on
> your machines for sshd entries, you should see them for logins and
> login attempts.
>
>> I'd already tried turning off PAM. I didn't have any authorized_keys
>> file. I also don't have id_dsa.pub; only id_rsa.pub. I copied this to
>> authorized_keys but no result.
>
> You might want to try authorized_keys2 instead, although first of all
> you need to figure out where you are sshing into!
>
--
Anthony Campbell
Yes, I wondered if that was what is happening. I don't know how I should
specify my own address from outside my own network.
Ian Rawlings
> I thought the right host to connect to would be a...@acampbell.org.uk
> since that is what I use for emails etc. I can connect to
> arcadia.acampbell.org.uk but that wouldn't work from a computer outside
> my newtwork, or would it?
No, your email address has very little to do with your externally
facing IP address, in many cases, absolutely nothing at all in fact.
I think you'd best contact your ISP for some clarification on the type
of IP address you have, fixed or dynamic, then break out your router
manual and start looking for "port forwarding".
Your network router will have an external IP address and will be the
only machine on your home network that is reachable from the internet,
so if you want to be able to get inside from the outside, you need to
find out what IP address your router has on the internet (not on your
own home network), then figure out a way to get it to accept
connections on a port of your choice and forward that through to port
22 on one of your internal machines in order to allow you to SSH into
it.
Be aware though that this will also allow anyone else to connect to
port 22 on your internal machine, so you will need to keep ssh up to
date, and make sure ssh is configured properly, as hackers routinely
try to log in using large numbers of usernames and passwords, so
either only allow public key authentication or make sure the machine
does not have any standard username and password combinations.
For more clarification I'd suggest googling for your router model and
the keywords "port forwarding".
Will Kemp
> On 2008-07-17, Ian <ian.g...@btinternet.com> wrote:
>> On 17 Jul, 15:59, Anthony Campbell <a...@acampbell.org.uk> wrote:
>>
>>> arcadia:~:$ ssh -v a...@acampbell.org.uk
>>> OpenSSH_4.7p1 Debian-12, OpenSSL 0.9.8g 19 Oct 2007
>>> debug1: Reading configuration data /etc/ssh/ssh_config
>>> debug1: Applying options for *
>>> debug1: Connecting to acampbell.org.uk [82.165.58.181] port 22.
>> That's the address of kundenserver.de. Since your domain is registered
>> with Schlund in Germany, I am wondering what exactly you are
>> connecting too. "Customer server" does not sound like your desktop
>> machine: it sound like something at Schlund.
>>
>> Ian
>
> Yes, I wondered if that was what is happening. I don't know how I should
> specify my own address from outside my own network.
Ah...
You're trying to ssh from the internet to your local network - and
you're assuming that, because you've got a domain (hosted somewhere
else, by the sounds of it) that's the address to use?
If it's (for example) a home network, using a standard ADSL or cable
internet connection, then - unless you've specifically set something up
- it's not in any way related to your domain (if i'm right in assuming
that's hosted somewhere else).
ADSL and cable internet services don't usually come with fixed IP
addresses - which means that each time your modem disconnects and
reconnects, you're likely to get a different network address.
If you want to be able to ssh to a machine that's connected to the
internet via such a service, you'll have to set up something like
dynamic dns ( http://dyndns.org and others). You'll probably also have
to configure your modem/router to forward incoming ssh connections to
the relevant machine. This isn't trivial - and if you don't know what
you're doing, you shouldn't do it, because it's likely to be a major
security hole that could allow a malicious attacker to take control of
your system.
Basically, this means you're not going to be able to do what you want to
do - unless you hire someone to set it up for you, or you've got plenty
of time to learn about the technicalities of networking.
You're probably better off trying to find another way to achieve what
you need to achieve.
Bernard Peek
Campbell <a...@acampbell.org.uk> writes
>Thanks for these clarifications. There are not two daemons running so
>the problem must be with the host I'm trying to connect to.
It is. I've just checked the DNS records and there is one for that host.
acampbell.org.uk has address 82.165.58.181
That obviously has an SSH server running but as it's not your machine
you don't have access to it.
>
>I thought the right host to connect to would be a...@acampbell.org.uk
>since that is what I use for emails etc. I can connect to
>arcadia.acampbell.org.uk but that wouldn't work from a computer outside
>my newtwork, or would it?
It would be possible to arrange that but it's a bit tricky and there are
security implications for your network. If you decide that it's what you
want to do then we can give you some more help. We would need to know
whether you have a static or dynamic IP address from your ISP.
--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.
Anthony Campbell
I see. This is bad news. I can ssh without problems within my own
network, from any of three machines to any other. But I go to Greece for
quite long periods and I was hoping to be able to access my computer in
England from there. I thought this was possible because I seem to hear
of a lot of people doing it.
I do have a static IP address and this is what I was using.
One of the main reasons for doing this was to be able to read my emails
from abroad. I can do this on the server I use either by webmail or
possibly by imap, but the spam filter on the server doesn't seem to work
so I have to wade through tons of spam each day.
Anthony Campbell
I looked myself up and my static address seems to be 87.127.32.23. I
tried to ssh to that but it said port 22 was blocked. That seems to be
due to my router; I therefore tried to open ssh access in the router and
now ssh just hangs indefinitely. So that is progress of a sort but I'm
a bit worried about possible security issues, although it seems to be
possible to specify a particular WAN address.
Will Kemp
What do you mean this is what you were using? According to your original
post you were trying to ssh to a domain name.
What network setup are you using? ADSL with modem/router?
What is the static IP address attached to? The modem/router?
How's the modem/router configured? Will it pass SSH connections through
to some host?
> One of the main reasons for doing this was to be able to read my emails
> from abroad. I can do this on the server I use either by webmail or
> possibly by imap, but the spam filter on the server doesn't seem to work
> so I have to wade through tons of spam each day.
I'd recommend making your life easy by using webmail. One thing i've
used in the past is redirecting email to my gmail account - gmail's spam
filtering is very good. Then you could read mail on gmail and write mail
on your webmail server (so it goes from the right address).
Tony Houghton
Ian Rawlings <new...@tarcus.org.uk> wrote:
> Be aware though that this will also allow anyone else to connect to
> port 22 on your internal machine, so you will need to keep ssh up to
> date, and make sure ssh is configured properly, as hackers routinely
> try to log in using large numbers of usernames and passwords, so
> either only allow public key authentication or make sure the machine
> does not have any standard username and password combinations.
I configure the router to forward a different external port to 22 on my
own PCs. This makes it a little harder for hackers, and also means I can
have different PCs on different external ports. As long as I remember
the right port when using remote clients... Rather than allow password
authentication it's better to carry a USB memory stick with your key
(and a copy of putty can be handy too).
--
TH * http://www.realh.co.uk
John Phillips
>> In message <slrng7uv...@arcadia.acampbell.org.uk>, Anthony
>> Campbell <a...@acampbell.org.uk> writes
>>>since that is what I use for emails etc. I can connect to
>>>arcadia.acampbell.org.uk but that wouldn't work from a computer outside
>>>my newtwork, or would it?
>>
>> It would be possible to arrange that but it's a bit tricky and there are
>> security implications for your network. If you decide that it's what you
>> want to do then we can give you some more help. We would need to know
>> whether you have a static or dynamic IP address from your ISP.
>
> I looked myself up and my static address seems to be 87.127.32.23. I
> tried to ssh to that but it said port 22 was blocked. That seems to be
> due to my router; I therefore tried to open ssh access in the router and
> now ssh just hangs indefinitely. So that is progress of a sort but I'm
> a bit worried about possible security issues, although it seems to be
> possible to specify a particular WAN address.
You usually need to do two things to get SSH to pass through a router.
I think you only did one of them.
1 allow port 22 traffic to pass through the firewall (I think you did
this)
2 make sure incoming port 22 traffic is directed by the router to the
specific server machine. Assuming you use NAT this will be in the
server setup section of the NAT setup.
As far as security is concerned there are several things you can do
with the sshd config file to harden usual sshd installs. If you
do get an external connection I am sure someone will tell you.
--
John Phillips
Tony Houghton
John Phillips <news...@DontUseThis.mainly.me.uk> wrote:
> You usually need to do two things to get SSH to pass through a router.
> I think you only did one of them.
>
> 1 allow port 22 traffic to pass through the firewall (I think you did
> this)
>
> 2 make sure incoming port 22 traffic is directed by the router to the
> specific server machine. Assuming you use NAT this will be in the
> server setup section of the NAT setup.
>
> As far as security is concerned there are several things you can do
> with the sshd config file to harden usual sshd installs. If you
> do get an external connection I am sure someone will tell you.
Another thing to bear in mind is that I remember having a router which
wouldn't allow me to connect from one PC on my LAN to another via the
public IP address, so you might not be able to confirm it's working
without using some other Internet account. ISTR someone here explaining
that there was a good reason for it, but I can't remember it.
Anthony Campbell
OK, got it! Shorewall was blocking access. Turning this off temporarily
allowed the connection to come up.
Thanks to all for advice and help. I'll have to check up the security
aspect before setting it up permanently.
Ian Rawlings
> Another thing to bear in mind is that I remember having a router which
> wouldn't allow me to connect from one PC on my LAN to another via the
> public IP address, so you might not be able to confirm it's working
> without using some other Internet account. ISTR someone here explaining
> that there was a good reason for it, but I can't remember it.
He can ask one of us to try and connect to his external IP address on
whatever port he wants to use, he'll be able to see that in the logs
as a failed SSH connection from a given IP address, so the port
forwarding part can be tested easily enough.
Will Kemp
Well, the main issues can be dealt with by disabling password login in
sshd_config and using RSA or DSA. That requires generating a
public/private key pair (with ssh-keygen), putting the public key in
.ssh/authorized_keys and having the private key available on the machine
you're connecting from (as someone else suggested, this could be on a
flash stick or something).
If you're carrying a laptop and will be connecting from that, then it's
simple. If you use windows or mac, putty can do ssh using the key. If
it's linux, the keys go in .ssh/id_dsa and .ssh/id_dsa.pub (or
id_rsa/id_rsa.pub).
You'll have to make the hole in shorewall permanent. And i'd recommend
not using port 22 on the router - i.e., use a different port to ssh to
and configure the router to forward that port to port 22 on the host.
This doesn't increase security but it does prevent silly script kiddies
from making a nuisance of themselves trying to crack your ssh security.
So long as you make sure the system with sshd running on it is fully
up-to-date - and in particular that you're using the latest version of
sshd - you should be about as safe as you can get.
There's one way to make it pretty much rock solid - and that's to
restrict the IP addresses that are allowed to connect to the ssh port.
If you know the address - or the subnet - that you'll be connecting
from, you can enable access from that/those address/es and deny it to
everything else. That's the only way to *really* make sure of security.
The rest of the above stuff on its own is second best - but still
reasonably safe.
Ian Northeast
> OK, got it! Shorewall was blocking access. Turning this off temporarily
> allowed the connection to come up.
>
> Thanks to all for advice and help. I'll have to check up the security
> aspect before setting it up permanently.
Make sure you are not allowing root to log in via ssh. If it is practical,
disallow access by password and allow only key based authentication, and
take your keys with you on a USB stick (and keep it safe:). Using a
different port number as someone suggested adds a little additional
security. I think that's sufficient for a home machine that no-one's going
to be desparate to crack.
Regards, Ian
Bernard Peek
<wi...@xxxx.swaggie.net> writes
>> One of the main reasons for doing this was to be able to read my emails
>> from abroad. I can do this on the server I use either by webmail or
>> possibly by imap, but the spam filter on the server doesn't seem to work
>> so I have to wade through tons of spam each day.
>
>I'd recommend making your life easy by using webmail. One thing i've
>used in the past is redirecting email to my gmail account - gmail's
>spam filtering is very good. Then you could read mail on gmail and
>write mail on your webmail server (so it goes from the right address).
You can configure gmail to use an alternative address. You will need to
prove that it really is yours, but once you have done that you don't
need to leave your mail server running.
Will Kemp
Yeah, you can set the "from" address, but it doesn't use it properly. I
can't remember exactly how it does it now, but to the users of most mail
clients, it still looks like it's coming from your gmail address - and i
think it sets a reply-to that points to gmail too. It's pointless using
that config really - i don't know why they bother offering it.
Anthony Campbell
Log in by root is not a llowed. This has been a very useful learning
experience; I never knew how to access my box from outside previously.
Once again, many thanks to all for advice.
Anthony
Jonathan Buzzard
Waste of time.
Keep your machine patched and up to date. Pick a *random* password and
remember it. Configure ssh to only allow those users that actually need to
be able to log in to log in.
For good measure pick usernames that are none obvious, i.e. jonathan would
be a really poor username.
I have never had a box compromised despite many years of being 24x7
connected with *much* better connectivity than a ADSL connection.
For example my logwatch output for today on my 24x7 connected ADSL box
60.191.220.143: 168 times
root/password: 15 times
admin/password: 7 times
test/password: 5 times
admins/password: 2 times
guest/password: 2 times
info/password: 2 times
pgsql/password: 2 times
richard/password: 2 times
sales/password: 2 times
user/password: 2 times
username/password: 2 times
web/password: 2 times
webmaster/password: 2 times
adam/password: 1 time
adm/password: 1 time
administrator/password: 1 time
agent/password: 1 time
alan/password: 1 time
alex/password: 1 time
alias/password: 1 time
amanda/password: 1 time
amavisd/password: 1 time
angel/password: 1 time
apache/password: 1 time
appowner/password: 1 time
appserver/password: 1 time
aptproxy/password: 1 time
backup/password: 1 time
bin/password: 1 time
brett/password: 1 time
clamav/password: 1 time
core/password: 1 time
cyrus/password: 1 time
cyrusimap/password: 1 time
daemon/password: 1 time
dan/password: 1 time
danny/password: 1 time
data/password: 1 time
david/password: 1 time
dean/password: 1 time
desktop/password: 1 time
divine/password: 1 time
eleve/password: 1 time
eppc/password: 1 time
frank/password: 1 time
ftp/password: 1 time
ftpuser/password: 1 time
games/password: 1 time
george/password: 1 time
gnats/password: 1 time
gopher/password: 1 time
halt/password: 1 time
harrypotter/password: 1 time
http/password: 1 time
httpd/password: 1 time
ident/password: 1 time
identd/password: 1 time
irc/password: 1 time
jabber/password: 1 time
james/password: 1 time
jeff/password: 1 time
john/password: 1 time
library/password: 1 time
linux/password: 1 time
list/password: 1 time
lp/password: 1 time
mail/password: 1 time
mailman/password: 1 time
mailnull/password: 1 time
master/password: 1 time
michael/password: 1 time
mike/password: 1 time
mysql/password: 1 time
named/password: 1 time
news/password: 1 time
newsletter/password: 1 time
nfsnobody/password: 1 time
nobody/password: 1 time
office/password: 1 time
operator/password: 1 time
oracle/password: 1 time
party/password: 1 time
paul/password: 1 time
pop/password: 1 time
popa3d/password: 1 time
postfix/password: 1 time
postgres/password: 1 time
postmaster/password: 1 time
proxy/password: 1 time
qtss/password: 1 time
radiomail/password: 1 time
recruit/password: 1 time
robert/password: 1 time
rpc/password: 1 time
rpcuser/password: 1 time
rpm/password: 1 time
samba/password: 1 time
sara/password: 1 time
search/password: 1 time
securityagent/password: 1 time
sgi/password: 1 time
shop/password: 1 time
shutdown/password: 1 time
smmsp/password: 1 time
snort/password: 1 time
spam/password: 1 time
ssh/password: 1 time
sshd/password: 1 time
staff/password: 1 time
stephen/password: 1 time
steven/password: 1 time
sunny/password: 1 time
susan/password: 1 time
sync/password: 1 time
sys/password: 1 time
telnetd/password: 1 time
tokend/password: 1 time
tomcat/password: 1 time
tony/password: 1 time
unknown/password: 1 time
users/password: 1 time
uucp/password: 1 time
virus/password: 1 time
visitor/password: 1 time
webadmin/password: 1 time
webpop/password: 1 time
windowserver/password: 1 time
workshop/password: 1 time
www-data/password: 1 time
www/password: 1 time
wwwrun/password: 1 time
xgridagent/password: 1 time
xgridcontroller/password: 1 time
zzz/password: 1 time
86.3.9.89 (cpc2-hudd7-0-0-cust344.hudd.cable.ntl.com): 380 times
root/password: 163 times
test/password: 6 times
admin/password: 5 times
user/password: 5 times
redtube/password: 4 times
user1/password: 4 times
andrew/password: 3 times
mail/password: 3 times
falcon/password: 2 times
guest/password: 2 times
mysql/password: 2 times
aaliyah/password: 1 time
abby/password: 1 time
abigail/password: 1 time
aidan/password: 1 time
alexa/password: 1 time
alexander/password: 1 time
alexandra/password: 1 time
alexis/password: 1 time
allison/password: 1 time
alyssa/password: 1 time
amanda/password: 1 time
amber/password: 1 time
amelia/password: 1 time
ana/password: 1 time
anna/password: 1 time
anthony/password: 1 time
apple/password: 1 time
arianna/password: 1 time
ashley/password: 1 time
ashlyn/password: 1 time
audrey/password: 1 time
austin/password: 1 time
autumn/password: 1 time
ava/password: 1 time
avery/password: 1 time
bailey/password: 1 time
ben/password: 1 time
benjamin/password: 1 time
brandon/password: 1 time
brian/password: 1 time
brianna/password: 1 time
brooke/password: 1 time
brooklyn/password: 1 time
caleb/password: 1 time
cameron/password: 1 time
carly/password: 1 time
caroline/password: 1 time
chloe/password: 1 time
christopher/password: 1 time
cjohnson/password: 1 time
claire/password: 1 time
cocolino/password: 1 time
connor/password: 1 time
courtney/password: 1 time
cyrus/password: 1 time
daniel/password: 1 time
danielle/password: 1 time
data/password: 1 time
demo/password: 1 time
design/password: 1 time
destiny/password: 1 time
dylan/password: 1 time
elizabeth/password: 1 time
ella/password: 1 time
emily/password: 1 time
emma/password: 1 time
erin/password: 1 time
ethan/password: 1 time
export/password: 1 time
faith/password: 1 time
fedora/password: 1 time
fly/password: 1 time
ftp/password: 1 time
ftpuser/password: 1 time
gabriella/password: 1 time
gabrielle/password: 1 time
gast/password: 1 time
gerry/password: 1 time
grace/password: 1 time
gracie/password: 1 time
guset/password: 1 time
hailey/password: 1 time
hannah/password: 1 time
http/password: 1 time
httpd/password: 1 time
install/password: 1 time
isabella/password: 1 time
isabelle/password: 1 time
jack/password: 1 time
jackson/password: 1 time
jacob/password: 1 time
jada/password: 1 time
james/password: 1 time
jasmine/password: 1 time
jayden/password: 1 time
jenna/password: 1 time
jessica/password: 1 time
jillian/password: 1 time
john/password: 1 time
jordan/password: 1 time
joseph/password: 1 time
joshua/password: 1 time
julia/password: 1 time
justin/password: 1 time
kaitlyn/password: 1 time
kate/password: 1 time
katherine/password: 1 time
katie/password: 1 time
kayla/password: 1 time
kaylee/password: 1 time
kendall/password: 1 time
kennedy/password: 1 time
knoppix/password: 1 time
kylie/password: 1 time
lauren/password: 1 time
leah/password: 1 time
lillian/password: 1 time
lily/password: 1 time
lindsey/password: 1 time
linux/password: 1 time
logan/password: 1 time
mackenzie/password: 1 time
madeline/password: 1 time
madison/password: 1 time
magazine/password: 1 time
maggie/password: 1 time
makayla/password: 1 time
marissa/password: 1 time
mary/password: 1 time
master/password: 1 time
matthew/password: 1 time
maya/password: 1 time
mckenna/password: 1 time
megan/password: 1 time
mia/password: 1 time
michael/password: 1 time
molly/password: 1 time
morgan/password: 1 time
murray/password: 1 time
natalie/password: 1 time
nathan/password: 1 time
newsroom/password: 1 time
nicholas/password: 1 time
nicole/password: 1 time
noah/password: 1 time
olivia/password: 1 time
oracle/password: 1 time
paige/password: 1 time
pass/password: 1 time
password/password: 1 time
peyton/password: 1 time
photo/password: 1 time
postgres/password: 1 time
postmaster/password: 1 time
public/password: 1 time
reagan/password: 1 time
rebecca/password: 1 time
research/password: 1 time
riley/password: 1 time
rootroot/password: 1 time
ryan/password: 1 time
samantha/password: 1 time
sarah/password: 1 time
savannah/password: 1 time
server/password: 1 time
service/password: 1 time
shelby/password: 1 time
sierra/password: 1 time
skylar/password: 1 time
sophia/password: 1 time
sophie/password: 1 time
sydney/password: 1 time
system/password: 1 time
tachel/password: 1 time
taylor/password: 1 time
temp/password: 1 time
test1/password: 1 time
teste/password: 1 time
tester/password: 1 time
testuser/password: 1 time
trinity/password: 1 time
tyler/password: 1 time
victoria/password: 1 time
web/password: 1 time
webmaster/password: 1 time
william/password: 1 time
www-data/password: 1 time
www/password: 1 time
www1/password: 1 time
zachary/password: 1 time
zoe/password: 1 time
86.4.178.133 (cpc1-ando3-0-0-cust644.sotn.cable.ntl.com): 1 time
root/password: 1 time
125.17.156.236: 87 times
root/password: 28 times
admin/password: 9 times
test/password: 7 times
guest/password: 4 times
fluffy/password: 3 times
webmaster/password: 3 times
info/password: 2 times
user/password: 2 times
username/password: 2 times
alan/password: 1 time
alex/password: 1 time
apache/password: 1 time
aron/password: 1 time
backup/password: 1 time
brett/password: 1 time
danny/password: 1 time
data/password: 1 time
ftp/password: 1 time
http/password: 1 time
httpd/password: 1 time
library/password: 1 time
linux/password: 1 time
master/password: 1 time
mike/password: 1 time
mysql/password: 1 time
network/password: 1 time
nobody/password: 1 time
oracle/password: 1 time
sales/password: 1 time
sharon/password: 1 time
shell/password: 1 time
shop/password: 1 time
unix/password: 1 time
webadmin/password: 1 time
word/password: 1 time
www-data/password: 1 time
None of which got anywhere as none of them are in the AllowUsers list. If
you actually bother to look at the passwords that get tried, then anyone
who gets compromised from these dictionary attacks deserves it.
JAB.
--
Jonathan A. Buzzard Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.
alexd
> None of which got anywhere as none of them are in the AllowUsers list.
> If you actually bother to look at the passwords that get tried, then
> anyone who gets compromised from these dictionary attacks deserves it.
From mine:
root/password from ::ffff:190.220.0.162: 121 Time(s)
root/password from ::ffff:61.34.78.200: 37 Time(s)
So if it didn't work the first time, why did they think it might work on
the 120 subsequent occasions?
--
<http://ale.cx/> (AIM:troffasky) (UnSoEs...@ale.cx)
09:53:57 up 7 days, 12:29, 3 users, load average: 2.61, 1.31, 0.51
Convergence, n: The act of using separate DSL circuits for voice and data
Tony Houghton
> On Thu, 17 Jul 2008 19:38:59 +0100, Tony Houghton wrote:
>
> > I configure the router to forward a different external port to 22
> > on my own PCs. This makes it a little harder for hackers, and also
> > means I can have different PCs on different external ports. As long
> > as I remember the right port when using remote clients... Rather
> > than allow password authentication it's better to carry a USB
> > memory stick with your key (and a copy of putty can be handy too).
> >
>
> Waste of time.
>
> Keep your machine patched and up to date. Pick a *random* password and
> remember it. Configure ssh to only allow those users that actually
> need to be able to log in to log in.
>
> For good measure pick usernames that are none obvious, i.e. jonathan
> would be a really poor username.
I think using a different port does help, because I reckon these scripts
would just go straight for port 22 rather than waste time scanning tens
of thousands of ports. Even if I'm confident they couldn't get the right
username and password I'd rather not have my bandwidth and logs taken up
by their attempts.
Ian Rawlings
> I think using a different port does help, because I reckon these scripts
> would just go straight for port 22 rather than waste time scanning tens
> of thousands of ports. Even if I'm confident they couldn't get the right
> username and password I'd rather not have my bandwidth and logs taken up
> by their attempts.
May I propose an experiment; run two SSH servers, one on normal, the
other on a random port, and see which one gets hit up the most ;-) I
suspect it'll be port 22 too, although I don't bother changing it myself.
Andrzej Adam Filip
> [...]
> Your network router will have an external IP address and will be the
> only machine on your home network that is reachable from the internet,
> so if you want to be able to get inside from the outside, you need to
> find out what IP address your router has on the internet (not on your
> own home network), then figure out a way to get it to accept
> connections on a port of your choice and forward that through to port
> 22 on one of your internal machines in order to allow you to SSH into
> it.
>
> Be aware though that this will also allow anyone else to connect to
> port 22 on your internal machine, so you will need to keep ssh up to
> date, and make sure ssh is configured properly, as hackers routinely
> try to log in using large numbers of usernames and passwords, so
> either only allow public key authentication or make sure the machine
> does not have any standard username and password combinations.
*and* use iptables on Linux to limit rate of SSH connections from single
IP address to limit "brute force" attacks - AFAIK ssh limits number of
password guesses in single ssh session.
[ e.g. 2 connections per 15 minutes ]
> For more clarification I'd suggest googling for your router model and
> the keywords "port forwarding".
--
[pl>en Andrew] Andrzej Adam Filip : an...@priv.onet.pl : an...@xl.wp.pl
A morsel of genuine history is a thing so rare as to be always valuable.
-- Thomas Jefferson
Nigel Wade
> On Thu, 17 Jul 2008 19:38:59 +0100, Tony Houghton wrote:
>
>> On Thu, 17 Jul 2008 18:33:07 +0100
>> Ian Rawlings <new...@tarcus.org.uk> wrote:
>>
>>> Be aware though that this will also allow anyone else to connect to
>>> port 22 on your internal machine, so you will need to keep ssh up to
>>> date, and make sure ssh is configured properly, as hackers routinely
>>> try to log in using large numbers of usernames and passwords, so
>>> either only allow public key authentication or make sure the machine
>>> does not have any standard username and password combinations.
>>
>> I configure the router to forward a different external port to 22 on my
>> own PCs. This makes it a little harder for hackers, and also means I can
>> have different PCs on different external ports. As long as I remember
>> the right port when using remote clients... Rather than allow password
>> authentication it's better to carry a USB memory stick with your key
>> (and a copy of putty can be handy too).
>>
>
> Waste of time.
Security wise, maybe. But not network or CPU load wise.
[snip attack stats]
>
> None of which got anywhere as none of them are in the AllowUsers list. If
> you actually bother to look at the passwords that get tried, then anyone
> who gets compromised from these dictionary attacks deserves it.
>
But everyone of those failed attempts is using up your network bandwidth and CPU
resources on the server, filling your logs etc. If you blocked port 22 and
moved sshd to another port chances are all that would disappear, it did for me.
I was getting around 1000 failed login attempts per hour on our servers until I
closed port 22 on the firewall and moved sshd to a different port for external
access. I just tell anyone who needs to access the servers from off-site what
port to use for ssh. Looking in the last 4 weeks logs I don't see a single
attempted ssh attack of the external ssh.
Pretty much every attempted login on ssh is script generated. They are not
intelligent enough to port scan for sshd on another port first. They just
attack port 22.
--
Nigel Wade
Ian Rawlings
> Pretty much every attempted login on ssh is script generated. They are not
> intelligent enough to port scan for sshd on another port first. They just
> attack port 22.
Another thing to watch out for is shoddy package installation routines
that install users on the system with default passwords, doesn't seem
to happen so much these days but used to happen. Another reason to go
for key-based authentication only, for machines that are internet
facing.
A half-decent script though would use something like nmap or amap to
protocol-check scanned ports, then the script can pick all ports that
run SSH and add them to the script, it's not hard to do, so moving
ports isn't much of a benefit in theory. In practice, running two SSH
daemons on different ports (one on standard, one on another port) and
seeing which gets hit the most, might show up big differences in hit
rates. That's the only real way to answer the question about whether
it's worth changing ports or not.
Chris Davies
> I configure the router to forward a different external port to 22 on my
> own PCs.
I also did this quite a while ago, and it's been very interesting to
see just by how much this simple change has cut down on the csript
kiddy attacks. (Getting close to 100%, for those who are curious.)
If (when) I do start to get non-22 attacks, I'll consider putting in a
rule triggered by probes to port 22 that blocks inbounds for a period
of time. (Port knocking? Yes, if necessary.)
Chris
alexd
> A half-decent script though would use something like nmap or amap to
> protocol-check scanned ports, then the script can pick all ports that
> run SSH and add them to the script, it's not hard to do, so moving ports
> isn't much of a benefit in theory.
In practice, scanning ~65000 ports over the internet can take a fair bit
of time, and if you DoS someone's router or firewall on the way you'll
soon come to the attention of those who can make your internet go away.
--
<http://ale.cx/> (AIM:troffasky) (UnSoEs...@ale.cx)
14:48:37 up 9 days, 17:23, 4 users, load average: 0.01, 0.05, 0.01
Ian Rawlings
> In practice, scanning ~65000 ports over the internet can take a fair bit
> of time, and if you DoS someone's router or firewall on the way you'll
> soon come to the attention of those who can make your internet go away.
It's quick if you're only scanning one host, takes less than an hour,
but if you're looking for SSH, then yes it's loads faster to scan an
address range for port 22 and start your script grinding, so a fair
point.
Will Kemp
> On Mon, 21 Jul 2008 11:38:05 +0100, Ian Rawlings wrote:
>
>> A half-decent script though would use something like nmap or amap to
>> protocol-check scanned ports, then the script can pick all ports that
>> run SSH and add them to the script, it's not hard to do, so moving ports
>> isn't much of a benefit in theory.
>
> In practice, scanning ~65000 ports over the internet can take a fair bit
> of time, and if you DoS someone's router or firewall on the way you'll
> soon come to the attention of those who can make your internet go away.
The other aspect of this, of course - and possibly the most important
one - is that if someone's using a non-standard ssh port they're
probably going to be harder to crack in other ways. Therefore, if you're
just on the lookout for an easy crack, you'll look somewhere else.
Why bother scanning every port on the off-chance there's an ssh daemon
somewhere? Because, if you do find one, you're probably not going to be
able to get into it anyway.
Using a non-standard ssh port is like putting a big padlock on a shed -
it doesn't make it any harder to get in, but it makes people think it
will be easier to look for a shed with a smaller padlock.
Jonathan Buzzard
Yeah, another complete urban myth. I suggest that you set up a machine,
and install cacti, munin or some other graphing program, then compare the
traffic flows and CPU load when you are under an ssh dictionary attack.
The reality is that for all the inconvenience of moving to a different port
you save negligible amounts of CPU and bandwidth. It ain't worth the
bother.
Jonathan Buzzard
> On 2008-07-21, Nigel Wade <n...@ion.le.ac.uk> wrote:
>
>> Pretty much every attempted login on ssh is script generated. They are not
>> intelligent enough to port scan for sshd on another port first. They just
>> attack port 22.
>
> Another thing to watch out for is shoddy package installation routines
> that install users on the system with default passwords, doesn't seem
> to happen so much these days but used to happen. Another reason to go
> for key-based authentication only, for machines that are internet
> facing.
Yeah, that is why you edit /etc/ssh/sshd_config and if not present add
a line that looks like this
AllowUsers user1 user2
If you cannot manage this you are not competent to run ssh on any public
facing computer.
In my opinion key-based authentication is for weenies that cannot cope
with random passwords. The biggest issue for me is that I would have to
carry the dam key with me wherever I go, and if I forget it then I am
stuffed.
Nick Leverton
Jonathan Buzzard <j...@somewhere.org> wrote:
>In my opinion key-based authentication is for weenies that cannot cope
>with random passwords. The biggest issue for me is that I would have to
>carry the dam key with me wherever I go, and if I forget it then I am
>stuffed.
Just out of interest, how do you cope with random passwords when you and
your colleagues have two or three hundred remote machines to maintain ?
What if a colleague leaves, do you re-generate passwords on them all
and then have to learn the new list ?
I assume you do have two or three hundred, anything much less might
count as weenie-dom in some quarters ... ;-)
Nick
--
Serendipity: http://www.leverton.org/blosxom (last update 6th June 2008)
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
Ian Rawlings
> In my opinion key-based authentication is for weenies that cannot cope
> with random passwords. The biggest issue for me is that I would have to
> carry the dam key with me wherever I go, and if I forget it then I am
> stuffed.
Random passwords are for weenies who can't cope with keeping a fecking
file safe! And if you forget your random password?
Nix
> AllowUsers user1 user2
>
> If you cannot manage this you are not competent to run ssh on any public
> facing computer.
AllowGroups is useful too, as is using them inside of Matches.
> In my opinion key-based authentication is for weenies that cannot cope
> with random passwords. The biggest issue for me is that I would have to
> carry the dam key with me wherever I go, and if I forget it then I am
> stuffed.
No random password that's short enough for you to remember it can
possibly have enough entropy to be secure. Keys have as much entropy as
you like (depending on how long you make them), with no human memory
burden, and the shortest has far more entropy than the longest password.
You really need a passworded keyphrase: that way at least you have two
parts of the security mantra: something you have and something you know.
Passwords alone only allow for one of those.
So if by `weenie' you mean `person with a clue about security' then I'm
proud to be a weenie. :)
Nix
> The reality is that for all the inconvenience of moving to a different port
> you save negligible amounts of CPU and bandwidth. It ain't worth the
> bother.
I used to think that way, but I rate-limited ssh connections last week when
I started to get massive parallel storms of ssh connections consuming >50Kb/s
bandwidth on my ADSL router and chewing up most of my CPU (of course there it
doesn't help that the sshd is running under user-mode-linux!).
Ian Rawlings
> You really need a passworded keyphrase: that way at least you have two
> parts of the security mantra: something you have and something you know.
> Passwords alone only allow for one of those.
I'm assuming you mean a passworded key, not keyphrase, as it fits the
description. That's what I use, a passworded key.
Nigel Wade
>
> The reality is that for all the inconvenience of moving to a different port
> you save negligible amounts of CPU and bandwidth. It ain't worth the
> bother.
>
There is no bother to running sshd on a different port. If you are not capable
of setting that up in less than 10 seconds you are not competent to be running
sshd on an Internet facing machine.
--
Nigel Wade
Nix
> On 2008-07-22, Nix <nix-ra...@esperi.org.uk> wrote:
>
>> You really need a passworded keyphrase: that way at least you have two
>> parts of the security mantra: something you have and something you know.
>> Passwords alone only allow for one of those.
>
> I'm assuming you mean a passworded key, not keyphrase, as it fits the
> description.
Yes, of course, slip of the brain.
> That's what I use, a passworded key.
I wish OpenSSH had a way to reject keys that didn't have passphrases:
at least the client should be able to do that, but it can't.
John Phillips
> Jonathan Buzzard <j...@somewhere.org> wrote:
>> Yeah, another complete urban myth. I suggest that you set up a machine,
>> and install cacti, munin or some other graphing program, then compare the
>> traffic flows and CPU load when you are under an ssh dictionary attack.
>>
>> The reality is that for all the inconvenience of moving to a different port
>> you save negligible amounts of CPU and bandwidth. It ain't worth the
>> bother.
>
> extremely unlikely to be launched against ssh on any port other than 22?
> It is true that other considerations may force a person or organisation to
> stick to port 22, but it really isn't much bother to run it on a different
> port; indeed, many people are forced to because they find themselves working
> somewhere that doesn't allow egress to port 22.
Just as a test I made the ssh port change to see in practice what
it takes. And I have to agree - it doesn't seem to be any real bother
at all.
- change the forwarding of port 22 in the NAT section of my router
config to forward the new port instead
- change the Port line in sshd_conf to the new port and re-start sshd
- change the port number in the client to the new port
And that was it. Less than five minutes.
I think I shall leave ssh on the new port. I have taken a snapshot of
the last month's ssh port attacks from auth.log and I will see how that
differs over the next month.
--
John Phillips
ne...@mellis.me.uk
<news...@DontUseThis.mainly.me.uk> wrote:
>Just as a test I made the ssh port change to see in practice what
>it takes. And I have to agree - it doesn't seem to be any real bother
>at all.
>
>- change the forwarding of port 22 in the NAT section of my router
> config to forward the new port instead
If you have done this then from outside your router your ssh port is
still 22.
>
>- change the Port line in sshd_conf to the new port and re-start sshd
>
>- change the port number in the client to the new port
>
>And that was it. Less than five minutes.
>
If you only want to change the external access then all that is needed
is to forward the new port to port 22 on the server. No server changes
are then needed.
ME
Jonathan Buzzard
> On 2008-07-21, Jonathan Buzzard <j...@somewhere.org> wrote:
>
>> In my opinion key-based authentication is for weenies that cannot cope
>> with random passwords. The biggest issue for me is that I would have to
>> carry the dam key with me wherever I go, and if I forget it then I am
>> stuffed.
>
> Random passwords are for weenies who can't cope with keeping a fecking
> file safe! And if you forget your random password?
>
I simply don't forget my passwords. I can keep a file safe, the issue is
having to carry it everywhere I go.
Jonathan Buzzard
> On 21 Jul 2008, Jonathan Buzzard uttered the following:
>> AllowUsers user1 user2
>>
>> If you cannot manage this you are not competent to run ssh on any public
>> facing computer.
>
> AllowGroups is useful too, as is using them inside of Matches.
>
>> In my opinion key-based authentication is for weenies that cannot cope
>> with random passwords. The biggest issue for me is that I would have to
>> carry the dam key with me wherever I go, and if I forget it then I am
>> stuffed.
>
> No random password that's short enough for you to remember it can
> possibly have enough entropy to be secure. Keys have as much entropy as
> you like (depending on how long you make them), with no human memory
> burden, and the shortest has far more entropy than the longest password.
Really, as secure as those Debian generated keys...
The point is that nobody is doing brute force ssh attacks. In nearly a
decade of having dozens of public internet facing machines on well
connected networks (that in todays terms means in excess of 1Gbps upstream
internet connected bandwidth) have I ever seen such an attack.
The reality is that it is simply not a feasible proposition. If you just
stick to an eight character password with a mixture of upper and lower
letters plus the digits, that is 218 trillion possible passwords. How do
you propose brute forcing that, especially if I rate limit login attempts
to one per second. It would take you the best part of 7000 millennium.
So the added aggravation of carrying a key around buys you zilch additional
security in reality.
> You really need a passworded keyphrase: that way at least you have two
> parts of the security mantra: something you have and something you know.
> Passwords alone only allow for one of those.
No I don't.
> So if by `weenie' you mean `person with a clue about security' then I'm
> proud to be a weenie. :)
I mean a person who thinks they are doing clever things to increase
security, causing additional hassle, achieving nothing of practical
value and based around the bizarre notion that random passwords are hard to
remember.
Jonathan Buzzard
> In article <np9fl5-...@small.buzzard.me.uk>,
> Jonathan Buzzard <j...@somewhere.org> wrote:
>
>>In my opinion key-based authentication is for weenies that cannot cope
>>with random passwords. The biggest issue for me is that I would have to
>>carry the dam key with me wherever I go, and if I forget it then I am
>>stuffed.
>
> Just out of interest, how do you cope with random passwords when you and
> your colleagues have two or three hundred remote machines to maintain ?
> What if a colleague leaves, do you re-generate passwords on them all
> and then have to learn the new list ?
LDAP + Kerberos, person leaves disable the account, job done.
> I assume you do have two or three hundred, anything much less might
> count as weenie-dom in some quarters ... ;-)
>
I do storage mainly, just a couple million GB. Depending on your outlook
that is either indeed weenie or fu$£%*g enormous.
Jonathan Buzzard
Never said there was, the hassle is in the usage. The bugger what random
port did I use when I am not at one of my main machines, and something has
gone wrong and I need to fix it. This is why I don't like keys either,
because again if I forget the dam key I am stuffed.
Ian Rawlings
> I simply don't forget my passwords. I can keep a file safe, the issue is
> having to carry it everywhere I go.
If you log in from untrusted machines then fine, use a one-time
password but not the same password on machines you don't own, I log in
from my laptops which have the key on them, password protected.
Nix
> On Tue, 22 Jul 2008 08:39:45 +0100, Nix wrote:
>> No random password that's short enough for you to remember it can
>> possibly have enough entropy to be secure. Keys have as much entropy as
>> you like (depending on how long you make them), with no human memory
>> burden, and the shortest has far more entropy than the longest password.
>
> Really, as secure as those Debian generated keys...
Well, duh, if your cryptosystem's PRNG is broken you're sort of screwed.
If you always pick passwords whose first four letters are 'A' you're
screwed too.
> The point is that nobody is doing brute force ssh attacks. In nearly a
Excellent. That's an even better reason to use a key rather than a
password: lots of people attack passwords, nobody attacks keys.
> decade of having dozens of public internet facing machines on well
> connected networks (that in todays terms means in excess of 1Gbps upstream
> internet connected bandwidth) have I ever seen such an attack.
I've seen a lot of dictionary attacks, but that's all remotely. I've
seen brute-force attacks from hostile insiders over a local net (yes,
it was obvious, but principally because he didn't clean the logs so the
disk filled up with error messages: he did it at night while rolling
compiles were running so the CPU usage wouldn't have been very
noticeable. We did notice that the compiles were taking longer...)
> The reality is that it is simply not a feasible proposition. If you just
> stick to an eight character password with a mixture of upper and lower
> letters plus the digits, that is 218 trillion possible passwords. How do
And you have to *remember* them. Nobody does. Everyone either writes
them down or carries them around on a USB stick. If they do that they
can carry around a key instead.
> you propose brute forcing that, especially if I rate limit login attempts
> to one per second. It would take you the best part of 7000 millennium.
Most passwords have *dramatically* less entropy than you suggest for the
simple reason that nobody can remember gibberish passwords. This is so
well known it's made the national news (along with the news that people
will give away their passwords --- or at least what they *say* is their
passwords --- for paltry rewards.)
> So the added aggravation of carrying a key around buys you zilch additional
> security in reality.
Passwords are definitely crackable: I've seen it done, over and over again.
Keys are not, without insane resources.
>> You really need a passworded keyphrase: that way at least you have two
>> parts of the security mantra: something you have and something you know.
>> Passwords alone only allow for one of those.
>
> No I don't.
OK, so you don't care about security. Great.
>> So if by `weenie' you mean `person with a clue about security' then I'm
>> proud to be a weenie. :)
>
> I mean a person who thinks they are doing clever things to increase
> security, causing additional hassle, achieving nothing of practical
> value and based around the bizarre notion that random passwords are hard to
> remember.
What hassle? It's not as if tracking a key is any harder than tracking
a gibberish password that you can't remember (in fact it's easier because
you don't need the key to be human-readable, and it's more secure not least
because you can passphrase it against someone nicking your key: if someone
nicks your written-down gibberish password you are dead meat.)
Ian Rawlings
> Passwords are definitely crackable: I've seen it done, over and over again.
> Keys are not, without insane resources.
More to the point, passwords are only more convenient if you are
logging in from locations on which you don't have the key,
i.e. machines that aren't under your control, and that's hardly a good
idea, no amount of random password gibberish will help there. Logging
in from your own machines with your password-protected keys on them,
with passwords disabled on the remote server, is the most secure
option.
Nix
> More to the point, passwords are only more convenient if you are
> logging in from locations on which you don't have the key,
> i.e. machines that aren't under your control, and that's hardly a good
> idea, no amount of random password gibberish will help there. Logging
Yeah, but then you're dead. The machine can copy your private key just
as easily as it can keylog you...
Ian Rawlings
Tsk, did you not read as far as the bit where I said logging in from
your *own* machines? No method of logging in from a machine you don't
control can really be regarded as secure, although this whole security
thing is generally an exercise in line-drawing. You can just as
easily draw the line at a point that even your own machines are
regarded as infested with thieving scum, but I'd have thought that for
most people running a business, opening up your network to a strange
machine via a persistent password would always be on the wrong side of
the line.
Nix
> On 2008-07-26, Nix <nix-ra...@esperi.org.uk> wrote:
>
>> On 25 Jul 2008, Ian Rawlings stated:
>>> More to the point, passwords are only more convenient if you are
>>> logging in from locations on which you don't have the key,
>>> i.e. machines that aren't under your control, and that's hardly a good
>>> idea, no amount of random password gibberish will help there. Logging
>>
>> Yeah, but then you're dead. The machine can copy your private key just
>> as easily as it can keylog you...
>
> Tsk, did you not read as far as the bit where I said logging in from
> your *own* machines?
Well, yes. I didn't comment on it because you were right. I commented
on what seems to be a flawed assumption here (even if it does support
my thesis).
Ian Rawlings
I think your assumption that my assumption is flawed is flawed!
I think.
Nix
> On 2008-07-26, Nix <nix-ra...@esperi.org.uk> wrote:
>
>> Well, yes. I didn't comment on it because you were right. I commented
>> on what seems to be a flawed assumption here (even if it does support
>> my thesis).
>
> I think your assumption that my assumption is flawed is flawed!
I'm floored.
> I think.
I am.
Jonathan Buzzard
> On 25 Jul 2008, Jonathan Buzzard spake thusly:
>> On Tue, 22 Jul 2008 08:39:45 +0100, Nix wrote:
>>> No random password that's short enough for you to remember it can
>>> possibly have enough entropy to be secure. Keys have as much entropy as
>>> you like (depending on how long you make them), with no human memory
>>> burden, and the shortest has far more entropy than the longest password.
>>
>> Really, as secure as those Debian generated keys...
>
> Well, duh, if your cryptosystem's PRNG is broken you're sort of screwed.
> If you always pick passwords whose first four letters are 'A' you're
> screwed too.
>
The point being that keys are not some panacia and those that think they
are, are silly.
>> The point is that nobody is doing brute force ssh attacks. In nearly a
>
> Excellent. That's an even better reason to use a key rather than a
> password: lots of people attack passwords, nobody attacks keys.
>
Wrong, people are currently attacking keys as well...
>> decade of having dozens of public internet facing machines on well
>> connected networks (that in todays terms means in excess of 1Gbps upstream
>> internet connected bandwidth) have I ever seen such an attack.
>
> I've seen a lot of dictionary attacks, but that's all remotely. I've
> seen brute-force attacks from hostile insiders over a local net (yes,
> it was obvious, but principally because he didn't clean the logs so the
> disk filled up with error messages: he did it at night while rolling
> compiles were running so the CPU usage wouldn't have been very
> noticeable. We did notice that the compiles were taking longer...)
>
You where allowing more than one login attempt per second...
>> The reality is that it is simply not a feasible proposition. If you just
>> stick to an eight character password with a mixture of upper and lower
>> letters plus the digits, that is 218 trillion possible passwords. How do
>
> And you have to *remember* them. Nobody does. Everyone either writes
> them down or carries them around on a USB stick. If they do that they
> can carry around a key instead.
>
Funny I seem to remember random passwords quite easily. In fact 99.99% of
people I know seem to be able to remember random sequences of numbers and
digits without problem. They are called telephone numbers and postcodes.
>> you propose brute forcing that, especially if I rate limit login attempts
>> to one per second. It would take you the best part of 7000 millennium.
>
> Most passwords have *dramatically* less entropy than you suggest for the
> simple reason that nobody can remember gibberish passwords. This is so
> well known it's made the national news (along with the news that people
> will give away their passwords --- or at least what they *say* is their
> passwords --- for paltry rewards.)
Do they, none of mine do, and any system admin who cannot pick a random
password and
>> So the added aggravation of carrying a key around buys you zilch additional
>> security in reality.
>
> Passwords are definitely crackable: I've seen it done, over and over again.
> Keys are not, without insane resources.
Only if you pick bunk passwords, just like if you generate bunk keys.
>>> You really need a passworded keyphrase: that way at least you have two
>>> parts of the security mantra: something you have and something you know.
>>> Passwords alone only allow for one of those.
>>
>> No I don't.
>
> OK, so you don't care about security. Great.
>
I do, which is why I have *never* had a compromised system that I have
been responsible for.
>
> What hassle? It's not as if tracking a key is any harder than tracking
> a gibberish password that you can't remember (in fact it's easier because
> you don't need the key to be human-readable, and it's more secure not least
> because you can passphrase it against someone nicking your key: if someone
> nicks your written-down gibberish password you are dead meat.)
Except my gibberish password is not written down anywhere, and I have no
issue remembering it. For anyone who can remember a sequence of eight
random characters, which I maintain is not hard to do, a key buys no
additional worthwhile security and a whole bunch of hassle.
Jonathan Buzzard
> On 2008-07-25, Nix <nix-ra...@esperi.org.uk> wrote:
>
>> Passwords are definitely crackable: I've seen it done, over and over again.
>> Keys are not, without insane resources.
>
> More to the point, passwords are only more convenient if you are
> logging in from locations on which you don't have the key,
> i.e. machines that aren't under your control, and that's hardly a good
> idea, no amount of random password gibberish will help there. Logging
> in from your own machines with your password-protected keys on them,
> with passwords disabled on the remote server, is the most secure
> option.
>
Perhaps, but another issue with keys is that you could be forced to
disclose the passphrase to your key should you take it through an airport.
With failure to do so leading to detention by the authorities. Compare
that to the password in my head.
I know which I would prefer...
Ian Rawlings
> Perhaps, but another issue with keys is that you could be forced to
> disclose the passphrase to your key should you take it through an airport.
> With failure to do so leading to detention by the authorities. Compare
> that to the password in my head.
Ridiculously unlikely given that the person at the airport would need
to know that SSH keys exist and of course, if they do, what use are
they as they don't actually contain kiddy porn or copied DVDs or
whatever the airport authorities are looking for; they are looking for
data on the laptop, and demonstrations that the laptop is a genuine
laptop, and an SSH key is not something they are looking for. Besides
it's easy to hide things.
So compare that to the much more likely scenario of your password
being snaffled because you're logging into your crown jewels from
untrusted machines...
> I know which I would prefer...
Your choice!
Jonathan Buzzard
> On 2008-07-29, Jonathan Buzzard <j...@somewhere.org> wrote:
>
>> Perhaps, but another issue with keys is that you could be forced to
>> disclose the passphrase to your key should you take it through an airport.
>> With failure to do so leading to detention by the authorities. Compare
>> that to the password in my head.
>
> Ridiculously unlikely given that the person at the airport would need
> to know that SSH keys exist and of course, if they do, what use are
> they as they don't actually contain kiddy porn or copied DVDs or
> whatever the airport authorities are looking for; they are looking for
> data on the laptop, and demonstrations that the laptop is a genuine
> laptop, and an SSH key is not something they are looking for. Besides
> it's easy to hide things.
>
> So compare that to the much more likely scenario of your password
> being snaffled because you're logging into your crown jewels from
> untrusted machines...
>
If the machine is untrusted it is game over whether you are using keys or
passwords. To suggest otherwise is foolish and uninformed.
The point is that if you have a random password, have rate limited the ssh
login attempts, banned system accounts and are using none obvious users
names, (all of which I do) then keys buy you little or no additional
security.
I would note that all of the above are sensible regardless of whether you
are using passwords or keys anyway.
Ian Rawlings
> If the machine is untrusted it is game over whether you are using keys or
> passwords. To suggest otherwise is foolish and uninformed.
That's right which I mentioned in the past in this thread, however you
earlier stated that you didn't want to use keys because you have to
take them with you, that's only a problem if the machines you are
logging in from are not yours. We've been through this before.
> The point is that if you have a random password, have rate limited the ssh
> login attempts, banned system accounts and are using none obvious users
> names, (all of which I do) then keys buy you little or no additional
> security.
You don't need to worry about the above if you ban password logins and
use password-protected keys on trusted machines, but from what you
have posted in the past, it seems you prefer to keep the same random
password for a long time, while logging in from all sorts of places.
Nix
> On Fri, 25 Jul 2008 20:27:16 +0100, Nix wrote:
>
>> On 25 Jul 2008, Jonathan Buzzard spake thusly:
>>> On Tue, 22 Jul 2008 08:39:45 +0100, Nix wrote:
>>>> No random password that's short enough for you to remember it can
>>>> possibly have enough entropy to be secure. Keys have as much entropy as
>>>> you like (depending on how long you make them), with no human memory
>>>> burden, and the shortest has far more entropy than the longest password.
>>>
>>> Really, as secure as those Debian generated keys...
>>
>> Well, duh, if your cryptosystem's PRNG is broken you're sort of screwed.
>> If you always pick passwords whose first four letters are 'A' you're
>> screwed too.
>
> The point being that keys are not some panacia and those that think they
> are, are silly.
If the cryposystem is not broken they have a hell of a lot more entropy than
passwords, and thus are more secure against certain attacks.
That doesn't make them a panacea. Have fun with that bonfire of straw.
>>> The point is that nobody is doing brute force ssh attacks. In nearly a
>>
>> Excellent. That's an even better reason to use a key rather than a
>> password: lots of people attack passwords, nobody attacks keys.
>
> Wrong, people are currently attacking keys as well...
I've not seen any attempts to attack anything but the weak keys from the
faulty Debian OpenSSL. Strong keys are simply not attacked. I've never
seen it and neither has anyone else I've ever talked to.
>>> decade of having dozens of public internet facing machines on well
>>> connected networks (that in todays terms means in excess of 1Gbps upstream
>>> internet connected bandwidth) have I ever seen such an attack.
>>
>> I've seen a lot of dictionary attacks, but that's all remotely. I've
>> seen brute-force attacks from hostile insiders over a local net (yes,
>> it was obvious, but principally because he didn't clean the logs so the
>> disk filled up with error messages: he did it at night while rolling
>> compiles were running so the CPU usage wouldn't have been very
>> noticeable. We did notice that the compiles were taking longer...)
>
> You where allowing more than one login attempt per second...
We have scripts that in effect require it. (Imagine how slowly some
things would run if *command executions* were limited to one per
second.)
>> And you have to *remember* them. Nobody does. Everyone either writes
>> them down or carries them around on a USB stick. If they do that they
>> can carry around a key instead.
>
> Funny I seem to remember random passwords quite easily. In fact 99.99% of
> people I know seem to be able to remember random sequences of numbers and
> digits without problem. They are called telephone numbers and postcodes.
Both of those are much too short to be a decent password, and, well,
could you remember your phone number and postcode if you kept on being
told to change it? (Personally I can't remember my phone number at
all. It has to compete for brainspace with countless passwords, PIN
numbers and other authenticators which I use much more often. How often do
you call your own phone?)
Also, phone numbers and postcodes are not authenticators, not secret,
and thus not comparable.
>> Most passwords have *dramatically* less entropy than you suggest for the
>> simple reason that nobody can remember gibberish passwords. This is so
>> well known it's made the national news (along with the news that people
>> will give away their passwords --- or at least what they *say* is their
>> passwords --- for paltry rewards.)
>
> Do they, none of mine do, and any system admin who cannot pick a random
> password and
You are unusual, most people are not system admins, and most passwords
are not chosen by system admins. Even passwords chosen by system admins
degrade to nonsafe states if (as, for instance, with the Windows
machines at my work) you are required to change them every week (every
week!)
>>> So the added aggravation of carrying a key around buys you zilch additional
>>> security in reality.
>>
>> Passwords are definitely crackable: I've seen it done, over and over again.
>> Keys are not, without insane resources.
>
> Only if you pick bunk passwords, just like if you generate bunk keys.
Sheesh. Do you *know* how bad these arguments of yours are?
>> What hassle? It's not as if tracking a key is any harder than tracking
>> a gibberish password that you can't remember (in fact it's easier because
>> you don't need the key to be human-readable, and it's more secure not least
>> because you can passphrase it against someone nicking your key: if someone
>> nicks your written-down gibberish password you are dead meat.)
>
> Except my gibberish password is not written down anywhere, and I have no
> issue remembering it. For anyone who can remember a sequence of eight
> random characters, which I maintain is not hard to do, a key buys no
> additional worthwhile security and a whole bunch of hassle.
Can you remember dozens of different sequences of eight random characters
when half of them are required to be changed on a regular basis, when others
get changed intermittently as a result of random compromises, and so on?
Because *that* is the world the rest of us live in. And it sucks.
Jonathan Buzzard
[SNIP]
>
> I've not seen any attempts to attack anything but the weak keys from the
> faulty Debian OpenSSL. Strong keys are simply not attacked. I've never
> seen it and neither has anyone else I've ever talked to.
Funny because I have not seen any attacks against strong passwords either...
[SNIP]
>>
>> Funny I seem to remember random passwords quite easily. In fact 99.99% of
>> people I know seem to be able to remember random sequences of numbers and
>> digits without problem. They are called telephone numbers and postcodes.
>
> Both of those are much too short to be a decent password, and, well,
> could you remember your phone number and postcode if you kept on being
> told to change it? (Personally I can't remember my phone number at
> all. It has to compete for brainspace with countless passwords, PIN
> numbers and other authenticators which I use much more often. How often do
> you call your own phone?)
>
> Also, phone numbers and postcodes are not authenticators, not secret,
> and thus not comparable.
>
The point is that people are capable of remembering a random string of
characters. That they don't when it is a password is something I don't
understand. However I maintain it is not due to inability. My personal
belief is, because it is not important to them.
[SNIP]
>
> You are unusual, most people are not system admins, and most passwords
> are not chosen by system admins. Even passwords chosen by system admins
> degrade to nonsafe states if (as, for instance, with the Windows
> machines at my work) you are required to change them every week (every
> week!)
Well yeah, that is a stupidly broken password policy. I am not quite sure
why people who are not sysadmins need ssh root level access either.
[SNIP]
>
> Sheesh. Do you *know* how bad these arguments of yours are?
>
You arguments are just as flawed. The problem is you have swallowed the key
hype. I agree it is more secure in theory. I maintain that in practise if
you can pick and remember a random password then the additional security
it affords is not significant.
If I know pi to 22 decimal places I can calculate the circumference of
Pluto's orbit to the nearest cm. If I know pi to 1,000,000 decimal places
I can calculated it to less than the diameter of a proton. However in the
real world I gained nothing of any practical value.
I would also point to the case of a certain admin in the USA that was
using just passwords. Even the vendor with bare metal access could not get
back in...
>>> What hassle? It's not as if tracking a key is any harder than tracking
>>> a gibberish password that you can't remember (in fact it's easier because
>>> you don't need the key to be human-readable, and it's more secure not least
>>> because you can passphrase it against someone nicking your key: if someone
>>> nicks your written-down gibberish password you are dead meat.)
>>
>> Except my gibberish password is not written down anywhere, and I have no
>> issue remembering it. For anyone who can remember a sequence of eight
>> random characters, which I maintain is not hard to do, a key buys no
>> additional worthwhile security and a whole bunch of hassle.
>
> Can you remember dozens of different sequences of eight random characters
> when half of them are required to be changed on a regular basis, when others
> get changed intermittently as a result of random compromises, and so on?
>
> Because *that* is the world the rest of us live in. And it sucks.
No I don't I need maybe half a dozen. However I don't and have never worked
anywhere with such broken password policies. Though I have worked at
places where they have even gone as far as implementing account lockouts
on failed logins. These have never lasted more than a few minutes though :-)
Jonathan Buzzard
> On 2008-07-31, Jonathan Buzzard <j...@somewhere.org> wrote:
>
>> If the machine is untrusted it is game over whether you are using keys or
>> passwords. To suggest otherwise is foolish and uninformed.
>
> That's right which I mentioned in the past in this thread, however you
> earlier stated that you didn't want to use keys because you have to
> take them with you, that's only a problem if the machines you are
> logging in from are not yours. We've been through this before.
>
You flaw is to assume that all the machines you are willing to trust have
your keys loaded. I maintain that this is not a reasonable assumption. I
also maintain that leaving my keys on all the machines that I would be
willing to trust at a given point in time is a really bad move. That
number could be in the hundreds and I might only visit individual machines
on an infrequent basis.
Ian Rawlings
> You flaw is to assume that all the machines you are willing to trust have
> your keys loaded.
If they have remote login access to my networks then there's going to
be very few of them and they're going to be very locked down, and I'll
take a laptop with an encrypted hard disc with me to log in rather
than spread my access about all over the place.
> I maintain that this is not a reasonable assumption. I also maintain
> that leaving my keys on all the machines that I would be willing to
> trust at a given point in time is a really bad move. That number
> could be in the hundreds and I might only visit individual machines
> on an infrequent basis.
Sounds like a recipe for disaster, whatever scheme you use.