alamise

Website URL:

How To scp, ssh and rsync without prompting for password

  • November 19, 2013
  • Published in CentOS 6

Whenever you need to use scp to copy files, it asks for passwords. Same with rsync as it (by default) uses ssh as well. Usually scp and rsync commands are used to transfer or backup files between known hosts or by the same user on both the hosts. It can get really annoying the password is asked every time. I even had the idea of writing an expect script to provide the password. Of course, I didn't. Instead I browsed for a solution and found it after quite some time. There are already a couple of links out there which talk about it. I am adding to it...

Lets say you want to copy between two hosts host_src and host_desthost_src is the host where you would run the scp, ssh or rsyn command, irrespective of the direction of the file copy!

    1. host_src, run this command as the user thatscp/ssh/rsync

    $ ssh-keygen -t rsa

    This will prompt for a passphrase. Just press the enter key. It'll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default~/.ssh/id_rsa.pub:

    Your public key has been saved in <your_home_dir>/.ssh/id_rsa.pub

  1. Transfer the id_rsa.pub file to host_dest by either ftpscp, rsync or any other method.

    1. host_dest, login as the remote user which you plan to use when youscp,ssh rsync host_src.
  1. Copy the contents of id_rsa.pub to ~/.ssh/authorized_keys2

$ cat id_rsa.pub >>~/.ssh/authorized_keys2
$ chmod 700 ~/.ssh/authorized_keys2

If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.

  1. Note that ssh by default does not allow root to log in. This has to be explicitly enabled on host_dest. This can be done by editing /etc/ssh/sshd_config and changing the option of PermitRootLoginfrom no to yes. Don't forget to restart sshd so that it reads the modified config file. Do this only if you want to use the root login.

Well, thats it. Now you can run scp, ssh and rsync on host_src connecting to host_dest and it won't prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting to host_src. You can reverse the steps above (generate the public key on host_dest and copy it to host_src) and you have a two way setup ready!

    SELinux 导致 PHP 无法使用 fsockopen 连接到 Memcached 服务器

    前段时间刚刚写了一篇关于 SELinux 导致 httpd(Apache2) 无法启动 的文章,今天又碰到 SELinux 的问题了。

    事情是这样的:

    首先是服务器硬盘出问题了:-(,我给换了块硬盘,然后重装系统(CentOS 5.4 i386),然后安装各种程序、还原各种数据。最后一步是使用 memcache.php 来监控 Memcache 状态。然而却发现该工具无法连接上 Memcached 服务器。经检查,Memcached 服务器已经正常启动,使用 telnet 能够正常连接上去,使用 Memcached 的应用程序(PHP程序)也正常工作。查看 memcache.php 代码发现其是使用 fsockopen 来连接 Memcached 服务器,遂怀疑 Socket 扩展的问题。然而,检查发现可以在命令行中使用 fsockopen 连接到任意地址的任意端口,说明 Socket 扩展没问题。但在 httpd 中使用 fsockopen 来就只能连接本机的 80、8080、443 端口,连接其他端口均失败。

    检查 httpd 的 log 也没发现任何问题。上网搜索也没发现类似问题,郁闷ing……

    于是又想到是否是 SELinux 的问题。grep 了下 /var/log/audit/audit.log,发现以下线索:

    [liang@www ~]$ sudo grep denied /var/log/audit/audit.log

    type=AVC msg=audit(1280882021.681:780): avc:  denied  { name_connect } for  pid=3822 comm="httpd" dest=11211 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket 
    type=AVC msg=audit(1280885410.800:805): avc:  denied  { name_connect } for  pid=3790 comm="httpd" dest=11211 scontext=user_u:system_r:httpd_t:s0 tcontext=system_u:object_r:http_cache_port_t:s0 tclass=tcp_socket

    看来又是 SELinux 搞的鬼。继续检查,发现 /var/log/messages 有以下错误信息:

    1. 4 08:11:59 www setroubleshoot: SELinux is preventing the http daemon from connecting to the itself or the relay ports For complete SELinux messages. run sealert -l 23d1381f-9d4b-439a-9ad6-d52f1025f247

    果然是 SELinux 引起的问题。根据提示继续检查:

    [liang@www ~]$ sealert -l 23d1381f-9d4b-439a-9ad6-d52f1025f247

    Summary:

    SELinux is preventing the http daemon from connecting to the itself or the relay 
    ports

    Detailed Description:

    SELinux has denied the http daemon from connecting to itself or the relay ports. 
    An httpd script is trying to do a network connect to an http/ftp port. If you 
    did not setup httpd to network connections, this could signal a intrusion 
    attempt.

    Allowing Access:

    If you want httpd to connect to httpd/ftp ports you need to turn on the 
    httpd_can_network_relay boolean: "setsebool -P httpd_can_network_relay=1"

    The following command will allow this access:

    setsebool -P httpd_can_network_relay=1

    Additional Information:

    Source Context                user_u:system_r:httpd_t 
    Target Context                system_u:object_r:http_cache_port_t 
    Target Objects                None [ tcp_socket ]

    ———————省略若干输出———————

    错误信息说得很明了了:SELinux 阻止了 httpd 的连接。修改方式也给出来了,以 root 身份运行以下命令即可:

    [liang@www ~]$ sudo /usr/sbin/setsebool -P httpd_can_network_relay=1

    注意该命令成功运行后没有任何输出。要检查是否设置成功,可以查看运行 getsebool 命令或者直接查看 log:

    [liang@www ~]$ /usr/sbin/getsebool httpd_can_network_relay 
    httpd_can_network_relay –> on

    [liang@www ~]$ sudo tail /var/log/messages

    1. 4 10:50:23 www setsebool: The httpd_can_network_relay policy boolean was changed to 1 by root

    设置成功了。重新刷新下 memcache.php, 发现已经能够正常工作了。job done!

    此文纯粹是工作备忘。但希望也能给碰到同样问题的朋友一点帮助。

      Reverse Proxy & Log Format

      • October 12, 2013
      • Published in Nginx

      Tip when you install ispconfig 3 behind a reverse proxy like nginx.

      In /etc/apache2/sites-available/ispconfig.conf changes '%h' to '%{X-Real-IP}i' to get this:

      Code:
      LogFormat "%v %{X-Real-IP}i %l %u %t \"%r\" %>s %B \"%{Referer}i\" \"%{User-Agent}i\"" combined_ispconfig

      In order to apache logs for awstats works properly.

      I've also defined in my /etc/nginx/nginx.conf config file:

      Code:
      proxy_set_header   X-Real-IP        $remote_addr;

      A better solution will be appreciated

        probleme de cookie suite à migration SPIP 3

        • October 5, 2013
        • Published in SPIP
        • Merci, 
          les tutos que tu m’a montré m’ont permis de résoudre partiellement mon problème .

          Création d’un fichier mes_options.php dans le répertoires ’config’
          en ajoutant comme ligne de code

          1. <?php
          2. if (function_exists("date_default_timezone_set"))
          3. date_default_timezone_set("Europe/Paris");
          4.  
          5. ini_set('display_errors','Off');
          6. ?>

          Télécharger

          ensuite lorsque je veux accéder à mon espace privée pour la première fois je désactive le fichier mes_options.php pour l’authentification puis je le réactive quand je suis logué sur l’espace privée . 
          et j’évite de me déconnecter afin de préserver mon cookie

          Je suis conscients que ce n’est pas très élaboré comme solution 
          mais en attendant une mise à jour de spip je n’en vois pas d’autre.


        • Pense aussi à enregistrer "mes_options.php" au format utf-8 sans BOM (avec Notepad++ par exemple). Cela n’a peut être rien à voir, mais j’ai vu que quelqu’un mentionnait ce point sur ces forum. Or j’ai eu récemment un bug qui m’a pris la tête pendant une demi-journée à cause de ça : mon machin marchait en local mais pas chez mon hébergeur. Je voyais bien que cela venait de ce fichier mais pas quelle était la ligne fautive. J’ai fini par vider totalement le fichier, à l’exception de

          1. <?php ?>

          et l’erreur subsistait ! C’était ce fichu format...

           

          结尾?>不要有空格

          如何显示隐藏的chrome扩展图标

          最近也不知是chrome升级的缘故,还是误操作,导致我的好几台电脑的chrome浏览器右侧的部分扩展程序的图标隐藏了,需要点“》”按钮展开,操作起来颇为不便。那怎么样重新显示被隐藏的chrome扩展图标呢?

          今天偶然发现,其实解决的方法很简单,就是将鼠标放置在地址栏的最右侧,也就是加书签的五角星右侧,鼠标会变成可拖动显示,这时向左拖动展开工具栏,隐藏的扩展应用图标就重新显示了。

          这个功能简单实用,我们可以通过调整扩展图标的位置,显示我们常用的图标(如switchysharp,词典),隐藏没用的图标(如ADBLOCK等)。

            nginx反向代理

            • September 27, 2013
            • Published in Nginx

            Nginx代理与负载均衡配置与优化

             Nginx代理

             Nginx0.7.48版本开始,支持了类似Squid的缓存功能。NginxWeb缓存服务主要由proxy_cache相关指令集和fastcgi_cache相关指令集构成,前者用于反向代理时,对后端内容源服务器进行缓存,后者主要用于对FastCGI的动态程序进行缓存。两者的功能基本上一样。

             Nginx 0.8.32版本,proxy_cachefastcgi_cache已经比较完善,加上第三方的ngx_cache_purge模块(用于清除指定URL的缓存),已经可以完全取代Squid

             在功能上,Nginx已经具备Squid所拥有的Web缓存加速功能、清除指定URL缓存的功能。而在性能上,Nginx对多核CPU的利用,胜过Squid不少。另外,在反向代理、负载均衡、健康检查、后端服务器故障转移、Rewrite重写、易用性上,Nginx也比Squid强大得多。这使得一台Nginx可以同时作为负载均衡服务器“Web缓存服务器来使用。

             下面的文档说明了nginx如何做代理服务器,将请求转发到其他服务器,本身不做缓存。使用版本为nginx-0.8.15,配置如下:

             http

            {

            ……..

                 client_max_body_size           300m          ;                  // 允许客户端请求的最大单个文件字节数

                     client_body_buffer_size       128k;         

                     // 缓冲区代理缓冲用户端请求的最大字节数,可以理解为先保存到本地再传给用户

                     proxy_connect_timeout          600;

                // 跟后端服务器连接的超时时间_发起握手等候响应超时时间

                // 连接成功后_等候后端服务器响应时间_其实已经进入后端排队之中等候处理

            1. 告诉nginx保存单个用的几个buffer最大用多大空间
             

            // proxy缓存临时文件的大小

                    server 192.168.0.110:80 weight=5;

                    server 192.168.0.121:80 weight=5;

                }

                upstream mysrv {

                    server 192.168.0.32:80 weight=2;

                    server 127.0.0.1:8000 weight=8;

                }

                server {

                    listen       80;

                    server_name  club.xywy.com;

                    charset gbk;

                    root  /www;

                    access_log logs/aaa.log combined;

            //下面是第一个域名,使用clubsrv的代理

                    location / {

                        proxy_next_upstream http_502 http_504 error timeout invalid_header;

            // 如果后端服务器返回502504或执行超时等错误,自动将请求转发到upstream另一台服务器

                        proxy_pass  http://clubsrv;>

            // 与上面upstream自己命名的名字填写一致

                        proxy_redirect     off;

                        proxy_set_header   Host            club.xywy.com;

                        proxy_set_header   X-Real-IP        $remote_addr;

                        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

            // nginx在前端做代理,后端的日志会显示127.0.0.1,上面配置可以显示用户真实IP(还需装第三方软件,见下面的详细说明)

                        index  index.htm index.html index.php;

                    }

            //下面是第二个域名,使用mysrv的代理,访问www.sum.com/message目录下的

                server {

                    listen       80;

                    server_name  www.sum.com;

                    location /message {

                       proxy_pass  http://mysrv;>

                       proxy_set_header   Host            $host;

            // 访问这个域名的,只有mysrv 本机可以访问

                      }

            //访问除了/message之外的www.sum.com/ 地址,

                    location / {

                       proxy_pass  http://mysrv;>

                       proxy_set_header   Host            $host;

                                 proxy_set_header   X-Real-IP       $remote_addr;

            下面的配置,与上面错误返回的效果相同,这里可以不写。

             

            error_page   500 502 503 504  /50x.html;  

            location = /50x.html

            {

               root   html;

            }

             

            2Nginx负载均衡指令 

            Nginx属于软件的七层负载均衡(lvs是软件的四层负载均衡的代表),七层负载均衡软件还有L7SWLayer7 switching)、HAProxy等。支持负载均衡的模块是Http Upstream。下面介绍此模块及他下面的几个指令 

            HTTP Upstream模块

             1ip_hash指令 

            当对后端的多台动态应用服务器做负载均衡时,ip_hash指令将某个客户端IP的请求通过哈希算法定位到同一台后端服务器上。这样,当来自某ip用户在Sever A上登录后,再访问该站点的其他URL时,能保证访问仍在Server A上。如果不加ip_hash,加入用户在Server A上登录,再访问该站点其他URL,就有可能跳转到后端的Sever BC…..,而session记录在A上,BC上没有,就会提示用户未登录。

            注意:但这种访问不能保证后端服务器的负载均衡,可能后端有些server接受到的请求多,有些server接受的少,设置的权重值不起作用。

            建议如果后端的动态应用程序服务器能做到session共享,而不用nginx上配置ip_hash的方式。

             

            upstream mysrv {

                    ip_hash;

                    server 192.168.0.110:80 weight=2;

                    server 127.0.0.1:8000 down;

                    server 192.168.0.212:80 weight=8;

                }

            2server指令

            该指令用语指定后端服务器的名称和参数。服务器的名称可以是一个域名,一个ip,端口号或UNIX Socket

            参数介绍:

            weight=number 设置服务器权重,权重值越高,被分配到客户端请求数越多。默认为1

            max_fails=numbser fail_timeout指定的时间内对后端服务器请求失败的次数,如果检测到后端服务器无法连接及发生错误(404除外),则标记为失败。如果没有设置,默认为1。设置为0则关闭这项检查。

            fail_timeout=time 在经历参数max_fails设置的失败次数后,暂停的时间。

            配置如下:

            upstream mysrv {

                    ip_hash;

                    server  www.xywy.com  weight=2;

                    server  127.0.0.1:8000   down;

                    server  192.168.0.212:80  max_fails=3  fail_timeout=30s;

                    server  unix:/tmp/bakend3;

                }

              为iptables规则添加注释

              • September 20, 2013
              • Published in CentOS 6

              iptables规则太多了,使用comment模块给iptables规则加上注释
              -A RH-Firewall-1-INPUT -i ppp+ -m comment –comment “Allow VPN clients connect any ports” -j ACCEPT

                Log iptables Messages to a Separate File with rsyslog

                • September 20, 2013
                • Published in CentOS 6

                Firewall logging is very important, both to detect break-in attempts and to ensure that firewall rules are working properly. Unfortunately, it’s often difficult to predict in advance which rules and what information should be logged. Consequently, it’s common practice to err on the side of verbosity. Given the amount of traffic that any machine connected to the Internet is exposed to, it’s critical that firewall logs be separated from normal logs in order to ease monitoring. What follows are two methods to accomplish this using iptables on Linux. The first method uses traditional syslog facility/priority filtering. The second, more robust method filters based on message content with rsyslog.

                The Old Way: Use a Fixed Priority for iptables

                The traditional UNIX syslog service only has two ways to categorize, and consequently route, messages: facility and priority. Facilities include kernel, mail, daemon, etc. Priorities include emergency, alert, warning, debug, etc. The Linux iptables firewall runs in the kernel and therefore always has the facility set to kern. Using traditional syslog software, the only way you can separate iptables messages from other kernel messages is to set the priority on all iptables messages to something specific that hopefully isn’t used for other kernel logging.

                For example, you could add something like the following to /etc/syslog.conf:

                kern.=debug -/var/log/iptables.log

                and specifically remove the kernel debugging messages from all other logs like so:

                kern.*;kern.!=debug -/var/log/kern.log

                and in each iptables logging rule use the command line option --log-level debug.

                There are two distinct disadvantages to this approach. First, there’s no guarantee that other kernel components won’t use the priority you’ve set iptables to log at. There’s a real possibility that useful messages will be lost in the deluge of firewall logging. Second, this approach prevents you from actually setting meaningful priorities in your firewall logs. You might not care about random machines hammering Windows networking ports, but you definitely want to know about malformed packets reaching your server.

                The New Way: Filter Based on Message Content with rsyslog

                1. rsyslog is mostly a drop-in replacement for a tradtional syslog daemon–on Linux, klogd and sysklogd. In fact, on Debian and Ubuntu, you can simply:

                $ sudo apt-get install rsyslog

                and if you haven’t customized /etc/syslog.conf, logging should continue to work in precisely the same way. rsyslog has been the default syslog on Red Hat/Fedora based systems for a number of versions now, but if it’s not installed:

                $ sudo yum install rsyslog

                Configure iptables to Use a Unique Prefix

                We’ll setup rsyslog to filter based on the beginning of a message from iptables. So, for each logging rule in your firewall script, add --log-prefix "iptables: ". Most firewall builder applications can be easily configured to add a prefix to every logging rule. For example, if you’re using firehol as I am, you could add:

                FIREHOL_LOG_PREFIX="firehol: "
                1. /etc/firehol/firehol.conf.
                2. /etc/rsyslog.d/iptables.conf with the following contents:

                Configure rsyslog to Filter Based on Prefix

                :msg, startswith, "iptables: " -/var/log/iptables.log
                & ~

                The first line means send all messages that start with “iptables: ” to /var/log/iptables.log. The second line means discard the messages that were matched in the previous line. The second line is of course optional, but it saves the trouble of explicitly filtering out firewall logs from subsequent syslog rules.

                When I configured this on my own machines, I did notice one issue that may be a peculiarity of firehol, but it’s probably worth mentioning anyway. It seems that firehol adds an extra single quote at the beginning of log messages that needs to be matched in the rsyslog rule. For example, here’s a log message from firehol:

                Apr 17 12:41:07 tick kernel: 'firehol: 'IN-internet':'IN=eth0 OUT= MAC=fe:fd:cf:c0:47:b5:00:0e:39:6f:48:00:08:00 SRC=189.137.225.191 DST=207.192.75.74 LEN=64 TOS=0x00 PREC=0x00 TTL=32 ID=5671 DF PROTO=TCP SPT=3549 DPT=5555 WINDOW=65535 RES=0x00 SYN URGP=0

                Notice the extra quote after “kernel: ” and before “firehol: “. So, on my machine I configured the rsyslog filter like so:

                :msg, startswith, "'firehol: " -/var/log/iptables.log
                & ~

                Configure iptables Log Rotation

                Finally, since we’re logging to a new file, it’s useful to create a log rotation rule. Create a file /etc/logrotate.d/iptables with the following contents:

                /var/log/iptables.log
                {
                	rotate 7
                	daily
                	missingok
                	notifempty
                	delaycompress
                	compress
                	postrotate
                		invoke-rc.d rsyslog reload > /dev/null
                	endscript
                }

                The preceding script tells logrotate to rotate the firewall log daily and keep logs from the past seven days.

                  Force iptables to log messages to a different log file

                  • September 20, 2013
                  • Published in CentOS 6

                  Force iptables to log messages to a different log file

                  1.  on OCTOBER 3, 2006 · 38 COMMENTS· LAST UPDATED FEBRUARY 23, 2008

                  According to man page:
                  Iptables is used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. Several different tables may be defined. Each table contains a number of built-in chains and may also contain user defined chains.

                  By default, Iptables log message to a /var/log/messages file. However you can change this location. I will show you how to create a new logfile called /var/log/iptables.log. Changing or using a new file allows you to create better statistics and/or allows you to analyze the attacks.

                  Iptables default log file

                  For example, if you type the following command, it will display current iptables log from /var/log/messages file:
                  # tail -f /var/log/messages
                  Output:

                  Oct  4 00:44:28 debian gconfd (vivek-4435): Resolved address "xml:readonly:/etc/gconf/gconf.xml.defaults" to a read-only configuration source at position 2
                  Oct  4 01:14:19 debian kernel: IN=ra0 OUT= MAC=00:17:9a:0a:f6:44:00:08:5c:00:00:01:08:00 SRC=200.142.84.36 DST=192.168.1.2 LEN=60 TOS=0x00 PREC=0x00 TTL=51 ID=18374 DF PROTO=TCP SPT=46040 DPT=22 WINDOW=5840 RES=0x00 SYN URGP=0
                  Oct  4 00:13:55 debian kernel: IN=ra0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:18:de:55:0a:56:08:00 SRC=192.168.1.30 DST=192.168.1.255LEN=78 TOS=0x00 PREC=0x00 TTL=128 ID=13461 PROTO=UDP SPT=137 DPT=137 LEN=58

                  Procedure to log the iptables messages to a different log file

                  Open your /etc/syslog.conf file:
                  # vi /etc/syslog.conf
                  Append following line
                  kern.warning /var/log/iptables.log
                  Save and close the file.

                  Restart the syslogd (Debian / Ubuntu Linux):# /etc/init.d/sysklogd restartOn the other hand, use following command to restart syslogd under Red Hat/Cent OS/Fedora Core Linux:# /etc/init.d/syslog restart

                  Now make sure you pass the log-level 4 option with log-prefix to iptables. For example:
                  # DROP everything and Log it
                  iptables -A INPUT -j LOG --log-level 4
                  iptables -A INPUT -j DROP

                  For example, drop and log all connections from IP address 64.55.11.2 to your /var/log/iptables.log file:
                  iptables -A INPUT -s 64.55.11.2 -m limit --limit 5/m --limit-burst 7 -j LOG --log-prefix '** HACKERS **'--log-level 4
                  iptables -A INPUT -s 64.55.11.2 -j DROP

                  Where,

                  • --log-level 4: Level of logging. The level # 4 is for warning.
                  • --log-prefix '*** TEXT ***': Prefix log messages with the specified prefix (TEXT); up to 29 letters long, and useful for distinguishing messages in the logs.

                  You can now see all iptables message logged to /var/log/iptables.log file:
                  # tail -f /var/log/iptables.log

                  Updated for accuracy.

                    Subscribe to this RSS feed
                    ( ! ) Warning: count(): Parameter must be an array or an object that implements Countable in /var/www/vhosts/shan.info/httpdocs/templates/gk_publisher/html/com_k2/templates/default/user.php on line 145
                    Call Stack
                    #TimeMemoryFunctionLocation
                    10.0006404336{main}( ).../index.php:0
                    20.04711322288Joomla\CMS\Application\SiteApplication->execute( ).../index.php:49
                    30.04711322288Joomla\CMS\Application\SiteApplication->doExecute( ).../CMSApplication.php:196
                    40.22102979440Joomla\CMS\Application\SiteApplication->dispatch( ).../SiteApplication.php:233
                    50.22163003784Joomla\CMS\Component\ComponentHelper::renderComponent( ).../SiteApplication.php:194
                    60.22223059112Joomla\CMS\Component\ComponentHelper::executeComponent( ).../ComponentHelper.php:377
                    70.22233076168require_once( '/var/www/vhosts/shan.info/httpdocs/components/com_k2/k2.php' ).../ComponentHelper.php:402
                    80.22973142936K2ControllerItemlist->execute( ).../k2.php:64
                    90.22973142936K2ControllerItemlist->display( ).../BaseController.php:710
                    100.23453232024K2ControllerItemlist->display( ).../itemlist.php:49
                    110.23453232024K2ControllerItemlist->display( ).../controller.php:19
                    120.23573250920Joomla\CMS\Cache\Controller\ViewController->get( ).../BaseController.php:663
                    130.23803271656K2ViewItemlist->display( ).../ViewController.php:102
                    140.33434284264K2ViewItemlist->display( ).../view.html.php:1407
                    150.33434284264K2ViewItemlist->loadTemplate( ).../HtmlView.php:230
                    160.33944350672include( '/var/www/vhosts/shan.info/httpdocs/templates/gk_publisher/html/com_k2/templates/default/user.php' ).../HtmlView.php:701