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 ac@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 - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Anthony Campbell  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 ac@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/

On 2008-07-17, Ian Rawlings  wrote:
> On 2008-07-17, Anthony Campbell  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 ac@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.
>
Thanks for reply; I confess to being fairly ignorant about ssh.
acampbe..org.uk is my domain name so I supposed I had to use
ac@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 ac@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
ac@acampbell.org.uk's password: 
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.


This is where things stop.

Anthony



-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Anthony Campbell  wrote:

> 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
> ac@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.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

On 2008-07-17, Ian Rawlings  wrote:
> On 2008-07-17, Anthony Campbell  wrote:
>
>> 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
>> ac@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!
>
It doesn't change when I try to login. This isn't good?


> 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.
-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Anthony Campbell  wrote:

> 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!

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

On 17 Jul, 15:59, Anthony Campbell  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

On 2008-07-17, Ian Rawlings  wrote:
> On 2008-07-17, Anthony Campbell  wrote:
>
>> 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 ac@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 - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Ian  wrote:
> On 17 Jul, 15:59, Anthony Campbell  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.

Anthony

-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Anthony Campbell  wrote:

> I thought the right host  to connect to would be ac@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".

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Anthony Campbell wrote:
> On 2008-07-17, Ian  wrote:
>> On 17 Jul, 15:59, Anthony Campbell  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.



-- 
http://MaldonIT.co.uk

In message , Anthony 
Campbell  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 ac@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.

On 2008-07-17, Will Kemp  wrote:
> Anthony Campbell wrote:
>> On 2008-07-17, Ian  wrote:
>>> On 17 Jul, 15:59, Anthony Campbell  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.
>

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 - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Bernard Peek  wrote:
> In message , Anthony 
> Campbell  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 ac@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.

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.


-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

Anthony Campbell wrote:
> On 2008-07-17, Will Kemp  wrote:
>> Anthony Campbell wrote:
>>> On 2008-07-17, Ian  wrote:
>>>> On 17 Jul, 15:59, Anthony Campbell  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.
>>
> 
> 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.

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).



-- 
http://MaldonIT.co.uk

On Thu, 17 Jul 2008 18:33:07 +0100
Ian Rawlings  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

On 2008-07-17, Anthony Campbell  wrote:
> On 2008-07-17, Bernard Peek  wrote:
>> In message , Anthony 
>> Campbell  writes
>>>I thought the right host  to connect to would be ac@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.
>
> 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

On 17 Jul 2008 18:43:46 GMT
John Phillips  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.

-- 
TH * http://www.realh.co.uk

On 2008-07-17, John Phillips  wrote:
> On 2008-07-17, Anthony Campbell  wrote:
>> On 2008-07-17, Bernard Peek  wrote:
>>> In message , Anthony 
>>> Campbell  writes
>>>>I thought the right host  to connect to would be ac@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.
>>
>> 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.
>

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. 

-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On 2008-07-17, Tony Houghton  wrote:

> 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.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Anthony Campbell wrote:
> On 2008-07-17, John Phillips  wrote:
>> On 2008-07-17, Anthony Campbell  wrote:
>>> On 2008-07-17, Bernard Peek  wrote:
>>>> In message , Anthony 
>>>> Campbell  writes
>>>>> I thought the right host  to connect to would be ac@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.
>>> 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.
> 
> 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. 

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.



-- 
http://MaldonIT.co.uk

On Thu, 17 Jul 2008 19:28:47 +0000, Anthony Campbell wrote:

> 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

In message <biMfk.43774$bt6.19857@newsfe14.ams2>, Will Kemp 
 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.




-- 
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.

Bernard Peek wrote:
> In message <biMfk.43774$bt6.19857@newsfe14.ams2>, Will Kemp 
>  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.

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.



-- 
http://MaldonIT.co.uk

On 2008-07-17, Ian Northeast  wrote:
> On Thu, 17 Jul 2008 19:28:47 +0000, Anthony Campbell wrote:
>
>> 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
>

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


-- 
Anthony Campbell - ac@acampbell.org.uk 
Microsoft-free zone - Using Debian GNU/Linux
http://www.acampbell.org.uk (blog, book reviews, 
and sceptical articles)

On Thu, 17 Jul 2008 19:38:59 +0100, Tony Houghton wrote:

> On Thu, 17 Jul 2008 18:33:07 +0100
> Ian Rawlings  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.

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.

On Sat, 19 Jul 2008 00:36:10 +0100, Jonathan Buzzard wrote:

> 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) (UnSoEsNpEaTm@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

In article <4881ac7d$0$636$bed64819@news.gradwell.net>,
	alexd wrote:
> On Sat, 19 Jul 2008 00:36:10 +0100, Jonathan Buzzard wrote:

>> 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?

Dictionary attack. It's not that they tried "password" as the password
repeatedly. The following is effective in blocking the simpler attacks.
If they try more than three connection attempts within any 3 minutes,
they're locked out. It's quietened the logs on several of my net-facing
servers.

#!/bin/sh
set -x

iptables -F INPUT

# SSH
# Accept trusted hosts
iptables -A INPUT -s 192.168.0.0/16 -p tcp -m tcp --dport ssh -j ACCEPT
iptables -A INPUT -s 172.16.0.0/14 -p tcp -m tcp --dport ssh -j ACCEPT
iptables -A INPUT -s 10.0.0.0/8 -p tcp -m tcp --dport ssh -j ACCEPT
iptables -A INPUT -s 127.0.0.0/8 -p tcp -m tcp --dport ssh -j ACCEPT

# For outsiders, rate-limit connections
iptables -A INPUT -p tcp -m tcp --dport ssh \
        -m state --state NEW \
        -m recent --hitcount 3 --seconds 180 --update -j DROP

iptables -A INPUT -p tcp -m tcp --dport ssh \
        -m state --state NEW \
        -m recent --set -j ACCEPT


-- 
Paul Martin

On Sat, 19 Jul 2008 00:36:10 +0100
Jonathan Buzzard  wrote:

> 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.

-- 
TH * http://www.realh.co.uk

On 2008-07-19, Tony Houghton  wrote:

> 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.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Tony Houghton  wrote:
>> 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.
>

You are right; this often isn't practical for a business but a
reasonable extra step for an individual.  Most people are never going to
be the victim of a directed, personal attack and the automated attacks
are only looking for ssh on port 22.

-- 
Bruce

What would Edward Woodward do?

Ian Rawlings  wrote:
> [...]
> 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 : anfi@priv.onet.pl : anfi@xl.wp.pl
A morsel of genuine history is a thing so rare as to be always valuable.
  -- Thomas Jefferson

Jonathan Buzzard wrote:

> On Thu, 17 Jul 2008 19:38:59 +0100, Tony Houghton wrote:
> 
>> On Thu, 17 Jul 2008 18:33:07 +0100
>> Ian Rawlings  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

On 2008-07-21, Nigel Wade  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.

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.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Tony Houghton  wrote:
> 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

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.

-- 
 <http://ale.cx/> (AIM:troffasky) (UnSoEsNpEaTm@ale.cx)
 14:48:37 up 9 days, 17:23,  4 users,  load average: 0.01, 0.05, 0.01
 Convergence, n: The act of using separate DSL circuits for voice and data

On 2008-07-21, alexd  wrote:

> 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.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

alexd wrote:
> 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.



-- 
http://MaldonIT.co.uk

On Mon, 21 Jul 2008 10:42:37 +0100, Nigel Wade wrote:

> Jonathan Buzzard wrote:
> 
>> On Thu, 17 Jul 2008 19:38:59 +0100, Tony Houghton wrote:
>> 
>>> On Thu, 17 Jul 2008 18:33:07 +0100
>>> Ian Rawlings  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.
>

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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

On Mon, 21 Jul 2008 11:38:05 +0100, Ian Rawlings wrote:

> On 2008-07-21, Nigel Wade  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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

In article ,
Jonathan Buzzard   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

On 2008-07-21, Jonathan Buzzard  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?

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

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.

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. :)

On 21 Jul 2008, Jonathan Buzzard stated:
> 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!).

On 2008-07-22, Nix  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.  That's what I use, a passworded key.

-- 
Blast off and strike the evil Bydo empire!
http://youtube.com/user/tarcus69
http://www.flickr.com/photos/tarcus/sets/

Jonathan Buzzard wrote:

> 
> 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

Jonathan Buzzard  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.

What price do you place on avoiding zero-day exploits, which are
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.

-- 
Bruce

I object to intellect without discipline.  I object to power without
constructive purpose. -- Spock

On 22 Jul 2008, Ian Rawlings uttered the following:

> On 2008-07-22, Nix  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.

On 2008-07-22, Bruce Richardson  wrote:
> Jonathan Buzzard  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.
>
> What price do you place on avoiding zero-day exploits, which are
> 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

On Mon, 21 Jul 2008 22:43:51 +0100, Ian Rawlings wrote:

> On 2008-07-21, Jonathan Buzzard  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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

On Tue, 22 Jul 2008 09:58:23 +0100, Nigel Wade wrote:

> Jonathan Buzzard wrote:
> 
>> 
>> 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.
>

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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

On Tue, 22 Jul 2008 08:39:45 +0100, Nix wrote:

> 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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

On Mon, 21 Jul 2008 21:38:19 +0000, Nick Leverton wrote:

> In article ,
> Jonathan Buzzard   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.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
St. Andrews, United Kingdom.

On 2008-07-24, Jonathan Buzzard  wrote:

> 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