On Thu, Jan 27, 2011 at 2:03 AM, Indunil Jayasooriya indunil75@gmail.com wrote:

On Thu, Jan 27, 2011 at 12:15 PM, Always Learning centos@g7.u22.net wrote:

...

Hallo,

I wanted to avoid typing-in my password every occasion I remotely logged-on to a server.

you expect Passwordless SSH. If so,

On your PC

# ssh-keygen -t rsa       ( passphrase should be empty )

NO!!! NO!!! NO!!! NO!!!

I'm sorry, but this is a far too comon and very, very bad practice. You may as well tape a Post-It note with your password on it under your keyboard, because anyone who can get this un-passphrase protected key will be able to automatically log in as you. The normal approach is to investigate how to use ssh-agent to store your unlocked key in an active session, not use a passphrase-less key. The "keychain" utiliti is very handy for just this purpose, and it's available in the RPMforge repositories for RHEL 5 and CentOS 5.

Far too many people say "but you have to trust your own machine!!!" and leave these passphrase-less keys lying around, and they're a popular vulnerability for crackers to steal if they can gain *any* access to your systems. It's particularly bad in environments that use NFS and allow local hosts to be run by local users: any such local admin can then "su" to become other users and access their private keys.

Also, there's a stack of reasons that DSA is preferred to RSA for SSH keys these days. When you generate your private keys, use "ssh-keygen -t dsa", not rsa.

Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again:

then,

# cd /root/.ssh/

Pls scp id_rsa.pub to the Server

# scp id_rsa.pub root@server:/root/.ssh/authorized_keys

Wrong again. Never use public key access for root accounts, it simply compounds the security risks. Passphrase protected SSH keys can be used, reasonably, for account access on other hosts, but should be avoided for root access. If you *HAVE* to use an SSH key for root, for example for "rsync" based backup operations, use rssh to restrict its operations or designate a permitted command associated with that key in the target's authorized_keys.

then, finally ssh to the server from your PC. it would be passwordless. pls see below

Sadly, this will *work*, but so does tying your car keys to your car door so you don't lose them. It's a security issue.

Please, read the manual pages on "ssh-agent" which was designed and built into SSH deployments for just such use.

On Thu, Jan 27, 2011 at 07:59:30AM +0000, John Hodrien wrote:

On Thu, 27 Jan 2011, Nico Kadel-Garcia wrote:

...

Wrong again. Never use public key access for root accounts, it simply compounds the security risks. Passphrase protected SSH keys can be

Is this actually current doctrine for typical machines? I thought plenty of people advocated restricting ssh to AllowRoot without-password. What exactly

Correct. PermitRootLogin without-password is the recommended approach if you must allow remote root login via ssh

It's even better to deny remote root at all (login as normal user then sudo/su as necessary), but practicallity says it's needed, so "without-password" will stop you from being able to use the password and force you to use public keys or other non-password authentication.

On Thu, 2011-01-27 at 06:40 -0500, Stephen Harris wrote:

*NEVER* use password authentication for root (passwords are easier to brute force 'cos people choose bad passwords). Use ssh public key access for root, with appropriate restrictions (eg "from=").

You haven't seen my long and difficult (for others) password (uppercase, lowercase, and digits). It is unlikely ever to succumb to brute force. :-)

On Thu, 2011-01-27 at 10:01 -0500, m.roth@5-cent.us wrote:

Always Learning wrote:

...

You haven't seen my long and difficult (for others) password (uppercase, lowercase, and digits). It is unlikely ever to succumb to brute force. :-)

Ah, no. Where can you log in as root from? If it's anywhere outside the intranet, bad, bad, bad.

Blush, blush .... access is on a non-standard port and then restricted to a few IP addresses. I don't want my servers taken over by others.

As a basic policy everything that can be changed from a default port is. That means I have open 25 and 80. Everything else has a none-standard port number of 4 or 5 digits. Definitely no 443. Every secure web application has https and a different port and IP restrictions (in the .htaccess).

I'm planning to experiment with mod_auth_mysql.

On Thu, 2011-01-27 at 10:27 -0500, m.roth@5-cent.us wrote:

Security through obscurity doesn't work.

It certainly helps defeat most potential intruders but not the most determined. IPtables does help too.

Are you familiar with nmap?

Yes. I used to read the bloke's circulars when I was on Windoze. Have it installed. Knowing I use Centos is not necessary going to assist anyone breaking-in if I have everything screwed firmly down.

Restricted to a few IP addresses is good; the fewer the better.

Currently 3 static IPs.

...

...

Security through obscurity doesn't work.

It certainly helps defeat most potential intruders but not the most determined. IPtables does help too.

We also run fail2ban at work. Very nice, installs (along with shorewall), and creates a temporary blacklist, blocking an IP that's tried five, I think, times to break in. All configurable, btw.

Here too and from my own systems those 'scriptkiddies' are exposed to the world using http://twitter.com/fail2ban :)

Regards,

Michel

On 01/27/2011 04:57 PM, m.roth@5-cent.us wrote: [snip]

...

Here too and from my own systems those 'scriptkiddies' are exposed to the world using http://twitter.com/fail2ban :)

So, where's most of your hits from? The most I see is China, followed by Brazil, then Korea (not sure which), then, a lot lower, Russia, Italy, and various others.

I see most hits come from India and China (218.0.0.0/16 - 223.0.0.0/16 seems rather popular) followed at quite a distance by the likes of Brazil, South Korea, Russia, Romania and Bulgaria.

Regards, Patrick

On Thu, 2011-01-27 at 20:30 +0100, Michel van Deventer wrote:

Lots from China, Russia and some South American countries. Sometimes even from my own country ! (Netherlands).

Attempts from Holland always, in my experience, come from Leaseweb IPs but complaining to them produces no results.

Mvg,

Paul.

P.S. 'Een brug te ver' I saw in Deventer when it was first released. Een mooi stad met een leuke binnenstad. I hope it is still the same.

Hi,

On Thu, 2011-01-27 at 20:30 +0100, Michel van Deventer wrote:

...

Lots from China, Russia and some South American countries. Sometimes even from my own country ! (Netherlands).

Attempts from Holland always, in my experience, come from Leaseweb IPs but complaining to them produces no results.

The most recent one came from a company in Amsterdam which stopped 5 minutes after I mailed the abuse address :)

P.S. 'Een brug te ver' I saw in Deventer when it was first released. Een mooi stad met een leuke binnenstad. I hope it is still the same.

I wouldn't know, my last name is 'van Deventer' but I have been only twice to Deventer in my life ;)

Regards,

Michel

On Thu, Jan 27, 2011 at 10:40:14AM -0500, m.roth@5-cent.us wrote:

We also run fail2ban at work. Very nice, installs (along with shorewall), and creates a temporary blacklist, blocking an IP that's tried five, I think, times to break in. All configurable, btw.

There is also denyhosts, which performs a very similar function. I believe both are available from the rpmforge repository (and probably in EPEL too if you prefer that repo).

--keith

On Thu, Jan 27, 2011 at 6:40 AM, Stephen Harris lists@spuddy.org wrote:

On Thu, Jan 27, 2011 at 02:39:29AM -0500, Nico Kadel-Garcia wrote:

...

Wrong again. Never use public key access for root accounts, it simply compounds the security risks. Passphrase protected SSH keys can be

That is 100% backwards.  *NEVER* use password authentication for root (passwords are easier to brute force 'cos people choose bad passwords). Use ssh public key access for root, with appropriate restrictions (eg "from=").

Nope. Ideally, use *neither* for root. Allow root access only from the local console or a local shell with "su", or "sudo" if you want to share access. That provides much superior tracking of the root access and whose account was used for the inappropriate access.

Remote root access in SSH should be avoided altogether, but if necessary, the SSH keys can be a big issue becuase of people who give exactly the advice we just saw. "Generate an unprotected key and publish it to the root account!" is, unfortunately, far too common, and we just saw someone suggest *exactly* that.

Root does not, generally, need password-free access. If it does, SSH keys can provide some restrictions on it, as can sudo for other accounts to allow them only specific root activities. But root access without making you actually put in a password and think about what you're doing is *begging* for pain.

In fact, the likely pain is only partially from stolen keys. It's also from people doing things as root without thinking about them, and making mistakes.

On 01/27/2011 01:39 AM, Nico Kadel-Garcia wrote:

Also, there's a stack of reasons that DSA is preferred to RSA for SSH keys these days. When you generate your private keys, use "ssh-keygen -t dsa", not rsa.

Care to elaborate on that? Searching, I find mostly a "stack of reasons" for preferring RSA now that its patent has expired, e.g.:

* DSA is critically dependent on the quality of your random number generator. Each DSA signature requires a secret random number. If you use the same number twice, or if your weak random number generator allows someone to figure it out, the entire secret key is exposed.

* DSA keys are exactly 1024 bits, which is quite possibly inadequate today. RSA keys default to 2048 bits, and can be up to 4096 bits.

Reasons for preferring DSA for signatures are less compelling:

* RSA can also be used for encryption, making it possible for misguided users to employ the same key for both signing and encryption.

* While RSA and DSA with the same key length are believed to be just about identical in difficulty to crack, a mathematical solution for the DSA discrete logarithm problem would imply a solution for the RSA factoring problem, whereas the reverse is not true. (A solution for either problem would be HUGE news in the crypto world.)

On Thu, Jan 27, 2011 at 12:33:31PM +0530, Indunil Jayasooriya wrote:

# ssh-keygen -t rsa ( passphrase should be empty )

Don't use passphraseless keys unless you're using it for an automated tool (eg rsync kicked off from cron). If this is for human interactive work then learn how to use ssh-agent.

(If it's for programmatic use then also learn the from= and command= options on the public key to restrict what the key can do)

on 14:50 Thu 27 Jan, Always Learning (centos@g7.u22.net) wrote:

On Thu, 2011-01-27 at 12:33 +0530, Indunil Jayasooriya wrote:

...

you expect Passwordless SSH. If so,

I wanted a quick effortless automated log-on.

That's what ssh-agent gives you.

If you invoke a command under ssh-agent, that comamnd (and all its children) inherit ssh-agent's environment, which includes the SSH_AUTH_SOCK variable, pointing to the authentication socket.

Only that user (or root, and you trust root, right) can access this socket.

For convenience (and some risk), you can also enable agent-forwarding (I prefer doing this to a limted set of hosts or domains). This would enable you to say:

ssh from localhost to adminbox.datacenter.example.com ssh from adminbox.datacenter.example.com to other hosts within the DC.

Very handy if you need to run quick commands, git pulls/pushes, scp, rsync, etc., within the DC, without having to constantly re-type your password.

Of course, the more often you type your password, the more memorable it becomes.

...

# ssh-keygen -t rsa ( passphrase should be empty )

Yes I did exactly that but following advice from this mailing list have changed to DSA and imposed a passphrase.

Either works. RSA takes merits. Password SHOULD be provided.

On Thu, Jan 27, 2011 at 2:35 AM, Cameron Kerr cameron@humbledown.org wrote:

On 27/01/2011, at 7:45 PM, Always Learning wrote:

...

Hallo,

I wanted to avoid typing-in my password every occasion I remotely logged-on to a server.

I created my SSH keys and copied the public part to the server and renamed it authorized_keys.

...

---

server /root/.ssh

id_rsa.authorized_keys  -rw--------

---

Your ~/.ssh/authorized_keys needs to be readable by sshd, your permissions on it are too restrictive (typically, this should be 0644)

No, 0600 is *fine* In fact that is the recommended permission from the man page for "ssh". OpenSSH does a bit of UID and EUID manipulation to gain permissions to examine that file as the user whose login is being attempted, precisely to deal with NFS mounted home directories which do not allow "root" direct access to protected files.

On 27/01/2011, at 8:48 PM, Nico Kadel-Garcia wrote:

And the permissions of $HOME/.ssh should be 0700.

Ah, yes. My mistake, sorry.

On 01/27/11 5:46 AM, Always Learning wrote:

-rw------- 1 root root 404 Jan 27 03:23 id_rsa.authorized_keys

how many times do you have to be told that the filename is authorized_keys, NOT id_rsa.authorized_keys

for someone who claims to have been in IT since the 1960s, you don't seem to pay much attention, and waste 100 messages on something generic and trivial for which there are 100s of 'HOWTOs' online.

If pw less access is something you prefer use a kerberos based service like FreeIPA/RedhatIPA. No need for ssh keys, and pw aren't stored locally. You can log in as a regular user and sudo su - to root, which can be done during ssh login: ssh -t user@host sudo su -

David

On Jan 27, 2011, at 1:35 AM, Cameron Kerr cameron@humbledown.org wrote:

On 27/01/2011, at 7:45 PM, Always Learning wrote:

...

Hallo,

I wanted to avoid typing-in my password every occasion I remotely logged-on to a server.

I created my SSH keys and copied the public part to the server and renamed it authorized_keys.

...

---

server /root/.ssh

id_rsa.authorized_keys -rw--------

---

Your ~/.ssh/authorized_keys needs to be readable by sshd, your permissions on it are too restrictive (typically, this should be 0644)

Also, it should be named authorized_keys, not id_rsa.authorized_keys

PS. Coming from a background in other distributions, I find it disturbing that Centos ships with allow_root_login defaulting to yes. If you really need this, ensure that you also restrict access from where people can log in, consider employing dynamic banning, and harden your sshd_config (which, oddly enough, you didn't post).

PPS. When diagnosing such faults, it can be useful to run the sshd (ie. the server process) in debugging mode, although this would generally require the server to be temporarily disabled so it can be started in debugging mode. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Hi all,

I am new at setting up icecastand was wondering if someone cold point me to a guide on how to do so on cent 5.5 or give my instructions

Best mike

Please do not hijack threads. If you want to send a new message to the list then do NOT reply to a message. Also, I ask that you first try to install icecast and *then* come to the list if you encounter problems. This is not an all-purpose support list. Thanks.

Kai

On Thu, 2011-01-27 at 20:35 +1300, Cameron Kerr wrote:

Also, it should be named authorized_keys, not id_rsa.authorized_keys

**************** B I N G O **************

I can now log-in with just my home made command .s2

Thanks a lot.

That cured it. Brilliant.

Many thanks again.