Jenkins SSH: Invalid PEM structure, ‘—–BEGIN…’ missing

Quick Solution

1. Paste the RSA private key (e,g. content of ~/.ssh/id_rsa) to Jenkins, like this:
2. Ensure the ~/.ssh/known-hosts in Jenkins master has agent/slave host key. Like:

   stdbuf -o0 -e0 ssh-keyscan -H  &>> ~/.ssh/known_hosts

3. Ensure the ~/.ssh/authorized_keys of Jenkins agent/slave has Jenkins master’s RSA key.
4. (Optional) if you can access the terminal of Jenkins master, test the connection by using:

   ssh 

Why?

Because the issue Presence of ECDSA SSH keys breaks SSH credentials plugin seems to affect the Jenkins masters that have both ECDSA and RSA.

Properly use gnome-keyring-daemon Enlightenment (E-17) with ssh-agent support

Now enlightenment (E-17) become my favorite  window manager because it looks elegant and have the most sane automatic tiling action that do not require you to remember lots of keyboard short-cut. However, I got tire on inputting passcode of ssh keys over and over again.

After some searching,  articles like https://wiki.archlinux.org/index.php/Enlightenment#Gnome_Keyring_integration and http://kill-0.com/duplo/2010/01/27/e17-and-the-gnome-keyring-daemon/ suggest that following code block in ~/.profile do the trick:

if [ -n "$GNOME_KEYRING_PID" ]; then
    eval $(gnome-keyring-daemon --start)
    export SSH_AUTH_SOCK
    export GNOME_KEYRING_CONTROL
    export GPG_AGENT_INFO
fi

After apply it, it did work, typing

ssh-add -L

returns all my keys, but I cannot use any network that manual password typing, the network manager applet shows “User authentication is required”, but the god-damn password dialog just not showing. Other than actually switch network, there is a command, seahorse,  can be used to spot this symptom. Just run

seahorse

enable View->By keyring, and look at upper left. If it does not have section “Password” or “Login”, then you are bitten by this bug.

Oh, I forgot to mention that I use lightdm as Display manager. In order to make the gnome-keyring work with it, /etc/pam.d/lightdm should look like:

auth [success=done ignore=ignore default=bad] pam_selinux_permit.so
...
auth optional pam_gnome_keyring.so 
auth include postlogin 
...
session optional pam_gnome_keyring.so auto_start 
session include postlogin

And if you need autologin, you need to do something similar to /etc/pam.d/lightdm-autologin

After some digging with journalctl  and systemd-loginctl, I found that .profile actually sourced twice, first is by /usr/bin/enlightenment_start (or lightdm), that one does not have ssh-agent associate with it, so calling gnome-keyring-daemon –start on that time let you neither be able to use network password dialog, nor the ssh keys are imported.

The second time is by /usr/bin/ssh-agent /bin/sh -c exec -l /bin/zsh -c “/usr/bin/enlightenment_start”,  you can safely call gnome-keyring-daemon now, as ssh-agent is now on.

So my ~/.profile ends like

if [ -n "$DESKTOP_SESSION" ];then 
    # No point to start gnome-keyring-daemon if ssh-agent is not up 
    if [ -n "$SSH_AGENT_PID" ];then 
        eval $(gnome-keyring-daemon --start) 
        export SSH_AUTH_SOCK export GPG_AGENT_INFO
        export GNOME_KEYRING_CONTROL
    fi
fi

One more thing, if you are using bash and has ~/.bash-profile, better to put above in to ~/.bash-profile.

zsh is similar, use ~/.zprofile instead.

Now be enlighten by enlightenment.

SSH Troubleshoot: Having valid key but still fall back to password

Do you have a valid key and the public key is ~/.ssh/authoried_keys of target ssh server, but you still need to type password? Here is the checklist you can refer:

1. ~/.ssh  and its content should not have read/write permission for other users
   cd ; chmod og-rw .ssh
2. Same goes with your remote directory ~/.ssh
3. Your server home directory should not have read/write permission for other users
   cd ~/..; chmod o-rw <homeDir>
4. If SELinux is enforced in server, make sure the SELinux type of ~/.ssh in server is user_ssh_home_tcd;  ls -dZ .ssh   # to list the SELinux type of ~/.ssh
   chcon -R -t user_ssh_home_t .ssh
5. ssh -vvv <login@server> to get more information on the local side.
6. See server log /var/log/secure for sshd output. Change LogLevel to DEBUG3  in /etc/ssh/sshd_config and restart sshd to get more detail debugging messages.
7. See server log /var/log/audit/audit.log for SELinux log.

Note that this checking is for Fedora and RHEL. Yet you can change the path of files to accommodate your system.

[HOWTO][SSH] provide multiple identity files.

Some development web site only allow one ssh public key, e.g. Fedora project.
It is not a problem if you use exactly one computer to submit the task.

However, if you do work on more than 2 computers then it might not work on the first glance.

Of course, the most naive resolution is just use the same SSH public/private for all the computers. I am not a security expert, but it does not seem right to me, plus, you might want other k

When digging in ssh_config man pages, it says:

IdentityFile

Specifies a file from which the user’s RSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_rsa and ~/.ssh/id_dsa for protocol version 2. Additionally, any identities represented by the authentication agent will be used for authentication. ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile.

The file name may use the tilde syntax to refer to a user’s home directory or one of the following escape characters: ‘%d’ (local user’s home directory), ‘%u’ (local user name), ‘%l’ (local host name), ‘%h’ (remote host name) or ‘%r’ (remote user name).

It is possible to have multiple identity files specified in configuration files; all these identities will be tried in sequence.

Thus, you can have a key pair, say, “id_rsa_fedora” and “id_rsa_fedora.pub” for signing fedora packages by writing your ~/.ssh/id_rsa_fedora like:

IdentityFile=~/.ssh/id_rsa_fedora

You do need to copy id_rsa_fedora to all you computers though.