Tạo bản ghost cho nhiều máy

http://www.vn-zoom.com/f94/tao-ban-ghost-cho-nhieu-may-456823.html

Vấn đề đa số các bạn dùng máy tính thường gặp phải là cài đặt lại phần mềm cho máy tính của mình, một công việc chẳng thú vị gì mấy đối với những người bận rộn. Tuy nhiên, điều đơn giản nhất để tránh sự nhàm chán đó là dùng chương trình Ghost để sao lưu (backup) lại ổ cứng của bạn ở tình trạng tốt nhất và sau khi bị sự cố thì ta chỉ cần phục hồi (restore) lại là xong ngay.


Nếu vấn đề chỉ đơn giản là vậy thì không có gì để nói! Thế nhưng khi bạn nâng cấp máy mới với một mainboard khác và bạn vẫn muốn giữ lại bộ Windows XP cũ của mình thì vấn đề lại xảy ra nếu mainboard cũ và mới không giống nhau. Nói cách khác là khi phần cứng có sự thay đổi thì việc bạn Ghost lại hệ điều hành Windows XP cũ có thể sẽ khiến máy tính chạy sẽ không được ổn định như cũ nữa, và có thể gây ra lỗi.

Để giải quyết vấn đề này ta làm như sau:

Bước 1: Cài đặt Windows XP và tất cả chương trình cần thiết.

Bước 2: Vào thư mục C:\WINDOWS\Driver Cache\i386, mở file Driver.cab rồi trích (Extract) các tập tin Atapi.sys, Intelide.sys, Pciide.sys, and Pciidex.sys vào thư mục C:\WINDOWS\System32\drivers.

Bước 3: Tạo tập tin tên Mergeide.reg bằng Notepad với nội dung như sau:

Trích:
Windows Registry Editor Version 5.00[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\primary_ide_channel]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”atapi”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\secondary_ide_channel]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”atapi”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\*pnp0600]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”atapi”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\*azt0502]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”atapi”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\gendisk]
“ClassGUID”=”{4D36E967-E325-11CE-BFC1-08002BE10318}”
“Service”=”disk”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#cc_0101]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_0e11&dev_ae33]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1039&dev_0601]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1039&dev_5513]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1042&dev_1000]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_105a&dev_4d33]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0640]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0646]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0646&REV_0 5]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0646&REV_0 7]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0648]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1095&dev_0649]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1097&dev_0038]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_10ad&dev_0001]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_10ad&dev_0150]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_10b9&dev_5215]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_10b9&dev_5219]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_10b9&dev_5229]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”pciide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_1106&dev_0571]
“Service”=”pciide”
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_1222]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_1230]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_2411]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_2421]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_7010]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_7111]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\
CriticalDeviceDatabase\pci#ven_8086&dev_7199]
“ClassGUID”=”{4D36E96A-E325-11CE-BFC1-08002BE10318}”
“Service”=”intelide”

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\atapi]
“ErrorControl”=dword:00000001
“Group”=”SCSI miniport”
“Start”=dword:00000000
“Tag”=dword:00000019
“Type”=dword:00000001
“DisplayName”=”Standard IDE/ESDI Hard Disk Controller”
“ImagePath”=hex(2):53,00,79,00,73,00,74,00,65, 00,6d,00,33,
00,32,00,5c,00,44,00,52,00,49,00,56,00,45,00,52,00 ,53,00,
5c,00,61,00,74 ,00,61,00,70,00,69,00,2e,00,73,00,79,00,73,
00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\IntelIde]
“ErrorControl”=dword:00000001
“Group”=”System Bus Extender”
“Start”=dword:00000000
“Tag”=dword:00000004
“Type”=dword:00000001
“ImagePath”=hex(2):53,00,79,00,73,00,74,00,65, 00,6d,00,33,
00,32,00,5c,00,44,00,52,00,49,00,56,00,45,00,52,00 ,53,00,
5c,00,69,00,6e,00,74,00,65,00,6c,00,69,00,64,00,65 ,00,2e,
00,73,00,79,00,73,00,00,00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\PCIIde]
“ErrorControl”=dword:00000001
“Group”=”System Bus Extender”
“Start”=dword:00000000
“Tag”=dword:00000003
“Type”=dword:00000001
“ImagePath”=hex(2):53,00,79,00,73,00,74,00,65, 00,6 ,00,33,
00,32,00,5c,00,44,00,52,00,49,00,56,00,45,00,52,00 ,53,00,
5c,00,70,00,63,00,69,00,69,00,64,00,65,00,2e,00,73 ,00,79,
00,73,00,00,00
Bước 4: Bây giờ bạn nhấp chuột phải vào tập tin Mergeide.reg và chọn Merge rồi nhấn Yes trong bảng thông báo của Windows.

Bước 5: Cuối cùng khởi động lại máy tính và cho chạy chương trình Ghost để tạo tập tin sao lưu. Vậy là bạn có được một bộ backup Windows XP tương thích với rất nhiều mainboard thông dụng rồi đó.

Securing SquirrelMail using HTTPS

http://www.differentpla.net/content/2004/03/securing-squirrelmail-using-https

Part 11 of Installing qmail and vpopmail. This part is about securing webmail access by using HTTPS.
At the end of Installing SquirrelMail, I'd finished installing webmail on my test box. Currently, this uses HTTP. This is not really secure enough for webmail, so this article is going to look at adding HTTPS access to webmail.

Apache-SSL or mod_ssl?

There are two options when it comes to providing support for HTTPS: Apache-SSL and mod_ssl. Debian has packages for both.
See these two mailing list posts (e.g.) for more information about which to choose:

http://lists.debian.org/debian-isp/2003/debian-isp-200304/msg00260.html

http://www.mail-archive.com/modssl-users@modssl.org/msg15791.html For this box, I'm going to use mod_ssl. My main motivation is that Apache-SSL runs as a separate daemon, which means that I'll have two sets of configuration files to maintain, and a bunch of apache-ssl processes using up memory even though this box won't be doing much HTTPS.

Installing mod_ssl

The first thing to do is to configure Apache to allow SSL access. As you'll recall, my test box is called flimsy, so we want to allow access to https://flimsy/. We do this (on Debian) by installing the libapache-mod-ssl package:

# apt-get install libapache-mod-ssl libapache-mod-ssl-doc

Information about configuring mod_ssl is in /usr/share/doc/libapache-mod-ssl-doc on Debian, but basically, you run mod-ssl-makecert to make yourself a certificate for testing, and then tweak your /etc/apache/httpd.conf file to turn on SSL. I'll talk about self-signed certificates (and installing them under Windows) later.
When Apache starts, it'll prompt for the passphrase used to protect the server certificate. See this for one way to work around this. Alternatively, you could just not enter a passphrase.
With a certificate installed using this method, you'll see a warning like the following:
When you create the certificate, you should specify the "Common Name" as the name by which clients will connect to this server. This is generally www.wherever.com. If you don't, you'll get a warning: "The name on the security certificate is invalid or does not match the name of the site" or similar.
For now, if you just hit "Yes", Internet Explorer will use the certificate for this session, allowing you to connect to the server.

Redirecting webmail to HTTPS

Now, currently, users can connect to the webmail using either HTTP or HTTPS. I'd like to force users to connect using HTTPS. This can be done with some mod_rewrite magic.
To make it go, put a .htaccess file in /var/www/webmail containing the following:

DirectoryIndex index.php

<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteCond %{SERVER_PORT}      !^443$
        RewriteRule ^(.*)$      https://%{SERVER_NAME}/webmail/$1 [L,R=303]
</IfModule>

If you prefer, you can probably put similar directives in a <Location> or <Directory> block in httpd.conf. Note that this stanza is protected by IfModule. This causes it to fall back to normal HTTP access if mod_ssl didn't load. In such a case, you might prefer to deny access to this directory entirely.

Self-Signed Certificates

In order to get rid of Internet Explorer's warning about the untrusted certificate, you need to have a signed certificate. For an e-commerce site, this is generally done by giving a stack of cash to VeriSign or Thawte. There are other Certificate Authorities, but these are the top two.
Alternatively, you can create a self-signed certificate and install it in Internet Explorer. For more information about how to do this see, for example, http://www.modssl.org/docs/2.8/ssl_faq.html#cert-ownca.
Note: If you're planning on using the same server key and certificate with BincIMAP, you'll need to remove the passphrase from the server key. BincIMAP has no way of prompting for the key and, due to the use of tcpserver, couldn't keep it anywhere anyway. For more information, see http://www.modssl.org/docs/2.8/ssl_faq.html#remove-passphrase.
If you follow the instructions given there to create a signed (or self-signed) certificate, you should end up with two files: server.crt and server.key. If you've installed Debian's mod_ssl, you should have directories named ssl.crt, ssl.csr and ssl.key in /etc/apache. I just put the files (in this example, I called them flimsy.key, flimsy.csr and flimsy.crt in those directories, and edited /etc/apache/httpd.conf to point to them:

<VirtualHost _default_:443>
     <IfModule mod_ssl.c>
        SSLEngine on
        SSLCertificateFile      /etc/apache/ssl.crt/flimsy.crt
        SSLCertificateKeyFile   /etc/apache/ssl.key/flimsy.key
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
     </IfModule>
</VirtualHost>

Installing a Self-Signed Certificate in IE

If, when presented with the certificate error message, you click on "View Certificate", you'll see your webserver's certificate.
You'd think that clicking the "Install Certificate" button would suffice, but it doesn't.
If you're using a self-signed certificate, you need to install your CA certificate in the "Trusted Root Certification Authorities" store. To to this, you can click on the "Certification Path" tab. This will show your server's certificate and your CA certificate. If you click on your CA certificate and click "View Certificate", you can view the details for your root CA certificate.
To install it, you first need to save it as a file. Select the "Details" tab and click the "Copy to File" button. If you then right-click on this file and select "Install Certificate" you'll see a wizard that will walk you through installing your CA certificate.
To see it, click on Tools / Options and go to the "Content" tab. Click on the "Certificates" button. Your certificate will be shown under "Trusted Root Certification Authorities".
Now you can point your browser at (in this example) https://flimsy.home.differentpla.net/webmail/ and it connects without bringing up any warnings.
For more information about Internet Explorer and certificates, read Chapter 6 - Digital Certificates in the Internet Explorer Resource Kit documentation.

Virtual Hosts and HTTPS

If you're using Virtual Hosts with Apache, you will run into what seems like a major problem: you can't use name-based virtual hosts and HTTPS. For more information, see http://www.modssl.org/docs/2.8/ssl_faq.html#vhosts.
Here are some possible different solutions:

• Use IP-based virtual hosts. This requires a different IP address for each virtual host. This can be done by installing more than one network card or by using IP aliasing with a single network card.
  Unfortunately, this won't work in my situation, because I've only got a single IP address for my DSL connection, and I'd need to upgrade my service and buy a router that supported more than one external IP address.
• Use a different port for each virtual HTTPS host. This would work in my case, but it's easy to forget to supply the port number when typing in the address.
• Don't worry about it. Use the same virtual host to access all of your mailboxes. This works with vpopmail, because the domain name is part of the username used to log in. You can do this as long as you don't mind that your users will see that all of your different domains are running off the same server. I don't particularly mind, so this is what I'll do.

Testing with Name-based Virtual Hosts

peculiar, my "production" server is already configured with several name-based virtual hosts. To try this out, I'll have to configure my test box in a similar fashion.
In Part 4, I configured my internal DNS so that both of my test domains would resolve to the same box. If I connect to http://flimsy.differentpla.test/ or http://flimsy.beerology.test/, I am presented with the same page.
Configuring name-based virtual hosts to handle this is very easy. Just put something like the following into /etc/apache/httpd.conf:

NameVirtualHost *

<VirtualHost *>
    ServerName flimsy.differentpla.test
    DocumentRoot /var/www/flimsy.differentpla.test
</VirtualHost>

<VirtualHost *>
    ServerName flimsy.beerology.test
    DocumentRoot /var/www/flimsy.beerology.test
</VirtualHost>

This is the minimum needed to get name-based virtual hosts to work. You'll probably want to configure more than just this for each virtual host. For example, peculiar has separate log files and custom error documents for each host.
Any requests that don't match a particular ServerName or ServerAlias directive will resolve to the first matching VirtualHost block.
We also need a minimal index.html in each of the DocumentRoot locations, e.g.:

<!--/var/www/flimsy.beerology.test/index.html-->
<html>
 <head><title>flimsy.beerology.test</title></head>
 <body>
  <h1>flimsy.beerology.test</h1>
 </body>
</html>

We ought also to tweak the DocumentRoot settings in the VirtualHost block responsible for HTTPS:

<VirtualHost _default_:443>
    DocumentRoot /var/www/flimsy.home.differentpla.net
    <IfModule mod_ssl.c>
        SSLEngine on
        SSLCertificateFile      /etc/apache/ssl.crt/flimsy.crt
        SSLCertificateKeyFile   /etc/apache/ssl.key/flimsy.key
        SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    </IfModule>
</VirtualHost>

If we don't do this, it'll be set to the default (/var/www on Debian), which is where each of our virtual hosts is installed. A user will be able to get a list of the virtual hosts on this box by browsing to http://flimsy.home.differentpla.net/. So, we change it.
Success! Users can connect to either of the name-based virtual hosts, and they can still connect to https://flimsy.home.differentpla.net/ to check their mail.
If a user inadvertently tries to connect to https://flimsy.differentpla.test, which resolves to the same site, they'll be presented with a warning message:

The user can choose "Yes", and they'll get the webmail login form as normal. In future, we'd probably prefer to use some mod_rewrite magic to redirect them to an information page if they've typed in the wrong address. We might also want to use mod_rewrite so that people who use HTTPS to connect to pages that don't need to be secure are redirected to use the HTTP variant, thus saving CPU cycles on the server.
Next: Securing IMAP.

• Internet Mail

• Add new comment

HowTo SSH/SCP without a password

HowTo SSH/SCP without a password.

 http://www.hostingrails.com/HowTo-SSH-SCP-without-a-password

This small HowTo will explain how to setup key-based authentication for password-less SSH and SCP usage.

This HowTo does assume the reader has some basic knowledge of ssh and a terminal, and is using an operating system that implements SSH. If you're using a Windows OS and want to use SSH, try PuTTY. For Putty, see key-based auth with Putty.

In the examples that follow please substitute 'servername' , 'ipaddress' and 'username' with the proper information for your setup. I have included a list of weblinks for the words in italic at the end of this document.

Step 1. Verify that you can connect normally (using a password) to the server you intend to setup keys for:

#### Examples ####

user@homebox ~ $ ssh username@'servername'

# Or:

user@homebox ~ $ ssh username@'ipaddress'

# If your username is the same on both the client ('homebox') and the server ('servername'):

user@homebox ~ $ ssh 'servername'

# Or:

user@homebox ~ $ ssh 'ipaddress'

# If this is your first time connecting to 'servername' (or 'ipaddress'), upon establishing a connection with the
# server you'll be asked if you want to add the servers fingerprint to the known_hosts file on your computer.
# Press 'enter' to add the fingerprint.

Step 2. Now that you're connected to the server and verified that you have everything you need for access (hopefully), disconnect by typing 'exit' .

#### Examples ####

user@servername ~ $ exit

# You should be back at:

user@homebox ~ $

Step 3. The next step is to copy a unique key generated on your 'homebox' to the server you are connecting too. First, before you generate a new key, check to see if you already have a key:

#### Example ####

user@homebox ~ $ ls -l ~/.ssh
total 20
-rwx--xr-x 1 user user  601 Feb  2 01:58 authorized_keys
-rwx--xr-x 1 user user  668 Jan  1 19:26 id_dsa
-rwx--xr-x 1 user user  599 Jan  1 19:26 id_dsa.pub
-rwx--xr-x 1 user user 6257 Feb  2 21:04 known_hosts

# The file we need to copy to the server is named id_dsa.pub. As you can see above, the file needed exists. You may or may not have other files in ~/.ssh as I do. If the key doesn't exist, however, you can make one as follows:

#### Example ####

user@homebox ~ $ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):     # Press 'enter' here
Enter passphrase (empty for no passphrase):     # Press 'enter' here
Enter same passphrase again:     # Press 'enter' here
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
6f:c3:cb:50:e6:e9:90:f0:0f:68:d2:10:56:eb:1d:91 user@host

# Entering a password when asked during the key generation processes when prompted would require you to enter a  password each time you SSH/SCP to the server which defeats the purpose of this document.

Step 4. Regardless whether you had a key ready to go or if you had to generate a new key, the next step is the same in either case. Now you're ready to copy the key to the server. Do so like this:

#### Example ####

user@homebox ~ $ ssh-copy-id -i ~/.ssh/id_dsa.pub user@'servername' (or 'ipaddress')

# If you are asked weather or not you wish to continue, say yes.

Step 5. Now it's time to test the setup. To do that, try to ssh to the server:

#### Example ####

user@homebox ~ $ ssh 'servername' (or 'ipaddress')

# You should log in to the remote host without being asked for a password.

Step 6. You can now SSH or SCP to the remote host without having to enter a password at each connection. To make sure your public key stays secure from prying eyes, do the following to change permissions and restrict access on 'homebox' and also on 'servername' to ~/.ssh:

#### Example ####

user@homebox ~ $ chmod 600 ~/.ssh/id_dsa ~/.ssh/id_dsa.pub

# Verify the permissions on the files:

#### Example ####

user@homebox ~ $ ls -l ~/.ssh
-rw-------  1 user user  668 Feb  4 19:26 id_dsa
-rw-------  1 user user  599 Feb  4 19:26 id_dsa.pub

Links

1. OpenSSH

2. known_hosts

3. fingerprint

------
Nice post!

I've noticed that I don't have the command ssh-copy-id on my OS X machine (I didn't even know one existed!). To achieve the same effect I usually do the following:

user@homebox ~ $ scp ~/.ssh/id_dsa.pub user@'servername':.ssh/authorized_keys

This is assuming you've already created a .ssh directory on your server 'servername' (just ssh in as normal and `mkdir .ssh`). This also assumes that you don't already have an `authorized_keys` file in the .ssh directory on your server. If you do just copy (scp) the id_dsa.pub file to a temporary file in your server's home directory and then

user@homebox ~ $ scp .ssh/id_dsa.pub user@servername:homebox_dsa.pub
user@homebox ~ $ ssh user@servername
user@servername ~ $ cat homebox_dsa.pub >> .ssh/authorized_keys
user@servername ~ $ rm homebox_dsa.pub 

If you've got it, the ssh-copy-id way is clearly a lot easier!

~ Mark

Hi Mark. Thanks for adding that bit. I don't have access to a Mac (new one anyway) so that's very nice to know.

Seth

Seth, I liked this post a lot, but felt the formatting and wording can be improved. I've made a few changes to the introduction.

Xin
(I wish I had used my name for my username now!)

-------

I found an elegant way of creating a new, or adding to an existing authorized_keys file with a single command:

ssh username@somedomain.com -n "echo `cat ~/.ssh/id_dsa.pub` >> ~/.ssh/authorized_keys"

-

I think it *is* a good practice to use pass phrases when using ssh keys. You can use ssh-agent on Linux and SSH Agent or SSHKeychain on Mac OS X, to avoid you to type your pass phrase everytime you access a remote host. Also, you can forward your keys using 'ssh -A' if you need to hop onto some host in the middle.

-- Igor"

-------

I'm using PUTTY (pageant) on a XP and on Vista.  I use 2048 RSA private key that is password protected.  I typically use PUTTY to connect, fyi: my purpose is really to be able to use git (which uses SSH) without having to log in every time I commit. Assuming you are too and have a key generated already...

load key into PuttyGen (enter password for the key) in the window copy the "public key for pasting into OpenSSH..." append this to the ~/.ssh/authorized_keys.  

One comment: when I used the append from above aka the elegant code, it did not add a \n at the end of the line aka didn't work. I vi'd the file added a new line.

--Eric

Problem tren qmail server voi error POP3, can send but can not receive on Microsoft outlook

cach giai quyet:       check lai permission tren folder Maildir/cur  all fai co quyen vpopmail.vchkpw tren all cac file.

Khong the log on vo squirelmail

http://www.bramschoenmakers.nl/en/node/270

bramschoenmakers.nl

Home

SquirrelMail: Unknown user or password incorrect

Submitted by Bram Schoenmakers on 19 October, 2007 - 13:08.

Tagged: Courier IMAP  •  FAM  •  FreeBSD  •  SquirrelMail

After having solved the problem described in previous entry, I encountered new problems with logging in.
Now, after I entered my credentials, the following error was shown:

Unknown user or password incorrect

The SquirrelMail website suggested that the IMAP server was misconfigured somehow. So I checked /var/log/maillog:

Oct 19 08:50:59 example imapd: LOGIN, user=test@example.com, ip=[127.0.0.1], protocol=IMAP
Oct 19 08:50:59 example imapd: LOGOUT, user=test@example.com, ip=[127.0.0.1], headers=0, body=0, rcvd=30, sent=238, time=0
Oct 19 08:50:59 example imapd: LOGIN, user=test@example.com, ip=[127.0.0.1], protocol=IMAP
Oct 19 08:50:59 example imapd: Failed to create cache file: maildirwatch (test@example.com)
Oct 19 08:50:59 example imapd: Error: Input/output error
Oct 19 08:50:59 example imapd: Check for proper operation and configuration
Oct 19 08:50:59 example imapd: of the File Access Monitor daemon (famd).
Oct 19 08:50:59 example imapd: Failed to create cache file: maildirwatch (test@example.com)
Oct 19 08:50:59 example imapd: Error: Input/output error
Oct 19 08:50:59 example imapd: Check for proper operation and configuration
Oct 19 08:50:59 example imapd: of the File Access Monitor daemon (famd).
Oct 19 08:50:59 example imapd: LOGOUT, user=test@example.com, ip=[127.0.0.1], headers=0, body=0, rcvd=431, sent=1438, time=0
Oct 19 08:50:59 example imapd: LOGIN FAILED, user=test@example.com, ip=[127.0.0.1]
Oct 19 08:51:04 example imapd: LOGOUT, ip=[127.0.0.1], rcvd=60, sent=332

Hmm, FAM didn't work really well, so I disabled it in the port and reinstalled it. Then, I restarted the IMAP server:

/usr/local/etc/rc.d/courier-imap-imapd.sh restart

But still, logging in didn't work. The FAM errors were gone, but the last two lines of the maillog output were still to be found.
It turned out that I hadn't restarted the courier-authdaemond. So restarting it:

/usr/local/etc/rc.d/courier-authdaemond restart

made the logins work flawlessly again. Hooray!
After that, I re-enabled FAM in the port. Loggin in still worked, but still those FAM errors spitted out in the maillog. I don't think it's really crucial so I'd better leave it out for now.

Cau hinh VPN cua IPcop voi Cisco ASA

   - IKE Encryption: 3DES

                  - IKE Integrity: MD5

                  - IKE Grouptype: MODP-1024

                  - IKE Lifetime: 8 hours

                  - ESP Encryption: AES-256bit

                  - ESP Integrity: SHA1

                  - ESP Grouptype: MODP-1536

                  - ESP Keylife: 8 hours

                  - Perfect Forward Secrecy (PFS) is marked

Lenh xem dung luong thu muc tren linux: du - Skh *