jenkins执行shell脚本，使用scp免密传输失败问题

Posted 2023-03-29

参考技术A 问题：Jenkins默认使用jenkins用户去启动，jenkins用户并没有权限去执行ssh免密登陆，所以导致执行失败

注：配置linux双机互信后，jenkins也需要将公钥加入到目标机器，才能达到shell脚本中scp免密传输的条件

一、验证登录

1、切换jenkins用户

# su jenkins

切换后还是root账号

2、分析解决：

2.1 应该是/etc/passwd文件中的/bin/bash被yum安装的时候变成了/bin/false

# vim /etc/passwd

jenkins:x:990:988:Jenkins Automation Server:/var/lib/jenkins:/bin/false( bash)

将bin/false改为/bin/bash

再次执行切换

# su jenkins

bash-4.1$

2.2  结果命令提示符的用户名不是jenkins而变成了 bash-4.1$，原因是在安装jenkins时，jenkins只是创建了jenkins用户，并没有为其创建home目录

# vim ~/.bash_profile

在文件的最后添加 export PS1='[\u@\h \W]\$'，执行文件使修改项起作用

# source ~/.bash_profile

验证是否成功   # su jenkins

二、为jenkins系统用户开启免密登录

1、在Jenkins的使用过程中，如果在脚本中使用到sudo命令，有可能出现如下所示的错误：

sudo: no tty present and no askpass program specified

这是因为Jenkins服务器在执行sudo命令时的上下文有误，导致这个命令执行的异常。

2.1 解决方法：

# sudo visudo

在文件末尾加上jenkins ALL=(ALL) NOPASSWD: ALL

2.2 重启jenkins，测试

# su jenkins

# sudo su -s /bin/bash jenkins

测试成功，jenkins免密登录成功。

PS：如果误操作修改了/etc/sudoers的权限来修改上述文件，则会导致如下所示的错误：

sudo :/etc/sudoers is world writable

sudo : no valid sudoers source found, quitting

sudo : unable to initialize poling plugin

这是Linux的一种保护机制。因此，如果出现上述误操作，则需要执行如下命令来解决：

$ pkexec chmod 0440 /etc/sudoers

三、jenkins用户开通ssh免密登录

1、安装ssh

# yum install ssh

1.1 将ssh服务设置开机自启

# sudo systemctl enable sshd

1.2 启动ssh

# sudo systemctl start sshd

2、生成jenkins用户秘钥证书

# su jenkins

# ssh-keygen -t rsa

2.1 查看是否生成成功

# /var/lib/jenkins/.ssh/

# ls

3、将公钥传输到目标linux系统

ssh-copy-id -i /var/lib/jenkins/.ssh/id_rsa.pub root@目标ip:path

------------------------------------------------------------------------------------------

参考：https://blog.csdn.net/weixin_43840640/article/details/90371472

Linux SSH , SCP 建立信任关系(免密传输)

最近有个需求,Jenkins需要将war传输到各个项目节点中,所以需要远程执行各个节点的shell脚本.但是中间有个输入密码的过程,在自动化部署中是行不通的,故需要增加免密登录.具体如下:

如果想在 A 这太机器上可以不需要密码就 ssh 到 B 、 C 两台机器上，可以采用如下的方法：

（ 1 ） 在 A 机器上： ssh-keygen -t rsa

　　期间要求输入的,直接回车

这个命令将为 A 上的用户生成其密钥对，询问其保存路径时直接回车采用默认路径，当提示要为生成的密钥输入passphrase 的时候，直接回车，也就是将 其设定为空密码。生成的密钥对 id_rsa ， id_rsa.pub ，默认存储在/home/username/.ssh 目录下。

(2) 在 A 机器上：将 id_rsa.pub 的内容复制到 A 、 B 、 C 三台机器 /home/username/.ssh/authorized_keys 文件中，如果机器上已经有 authorized_keys 这个文件了，就在文件末尾加上 id_rsa.pub 中的内容，如果没有 authorized_keys 这个文件，直接 cp 或者 scp 就好了，下面的操作假设各个机器上都没有 authorized_keys 文件。（如果 B 、 C 机器上没有 ~/.ssh 目录可以手动自己创建 , 权限要设置成可以写，因为要 copyauthorized_keys)

  在A机器上 ： cp id_rsa.pub authorized_keys

   在 B 和 C ： scp authorized_keys [email protected]:~/.ssh/ 此处的 username 是要访问的 B 机器上的用户名。

 

 

 

如果机器中已经存在authorized_keys文件，则需注意，这个文件可以包含多个SSH验证信息，这时可用 cat >>命令将验证文件内容附加上去。

 

比如复制到scp .ssh/id_rsa.pub 192.168.10.2:/root/.ssh/a.pub

 

然后执行cat ~/.ssh/a.pub >> ~/.ssh/authorized_keys

 

 

 

(3) 在B和C机器上:  chmod 644 authorized_keys
  这一步非常关键，必须保证 authorized_keys 只对其所有者有读写权限，其他人不允许有写的权限，否则 SSH 是不会工作的

(4) 可以直接 ssh [email protected] 机器名了，同一台机器的不同用户直接也可以以这种方式来访问

 

如果经过上面的步骤还是提示需要密码，注意一下权限问题，主要有三个权限

  (1) /home/username这目录的权限应该是700

  (2) /home/username/.ssh 这个目录的权限也应该是700

  (3) /home/username/.ssh/ authorized_keys这个文件的权限是644

如果还是不正确，那么tail /var/log/secure一下这个日志文件，就能发现问题。

 

 转载文章:https://blog.csdn.net/xqhrs232/article/details/71159718