Due to some reason, I have to use "setsid" to run all of my commands.
But, when running "setsid scp ~/aaa user1#10.170.3.17:/tmp/", a dialog box requesting for password arose.
Normally, the prompt arises in command line.
Does it caused by some configuration in ssh?
I want to eliminate the box. How to achieve it?
One of the effects of the setsid command is that process that is started via setsid(1) is detached from it's controlling terminal. Without controlling terminal, scp cannot ask for the password on the terminal from which it was started simply because it does not "see" any. However, what it does "see" is the environment variable telling it that there is an X11 window session where it can show a graphical utility to ask you for the password or passphrase needed to unlock the private SSH key which will be used to authenticate to the remote system.
Even if you would unset the environment variable that it "sees" and uses it to route the x11-ssh-askpass dialogue to your screen (DISPLAY), that would probably not produce the desired effect for you, since required key would be missing and scp operation would fail.
One of solutions that I would recommend here would be setting up a "passwordless" login (if applicable in given security circumstances), using ssh-keygen(1) to produce "identity keys" that will not be password-protected.
You might explore other possibilities, for example providing passphrase in a file or on command line option, whatever works better for you. Please have a look in the ENVIRONMENT section of ssh(1) manpage.
Related
Problem:
I would like to use python's keyring library in a headless Linux environment, specifically a Debian 9 GCP compute instance. I have a cron job that wakes up every so often to run a python script (... which utilizes keyring to retrieve passwords to various resources).
The problem is that the python script will prompt for the user's keyring password before allowing the python script to proceed. This does not work as the script is executed as a background cron process. Interestingly, running this same script in a Windows environment is not an issue, presumably because the process (user) is already authenticated.
Research:
I've only found one StackOverflow post (here) and the official online documentation (here - 'Using Keyring on headless Linux systems') that has a short section on how to run keyring in a headless linux environment.
The StackOverflow post covers how to do this with pgcli, but not any arbitrary command line tool (e.g. my python script), thus I did not find it helpful.
Similarly, I have not been able to successfully reproduce the steps (it feels like there are steps missing?) in the doc to effect. Explicitly, after doing dbus-run-session -- sh, I run gnome-keyring-daemon --unlock, but the dbus-run-session just appears to hang and does not appear to execute anything).
Questions:
1) Does anyone have, can provide clear instructions on how to run keyring in a headless Debian Linux environment, given my above scenario? Explicitly - no password prompting. I would really appreciate very explicit, step by step instructions if possible.
2) If not, I am using keyring to retrieve passwords to various resources (e.g. postgres, remote API keys, etc.). I was hoping to secure these in a keyring, but if not possible what would be the recommended alternative? I read a few StackOverflow posts on storing data such as this in environment variables, but that is not recommended. I also feel that creating a config file and then encrypting it seems heavy.
Any help is appreciated. Thank you kindly -
I've just tried it the instructions you pointed to and they worked. gnome-keyring-daemon --unlock is not hanging, it's reading your password from stdin, i.e. you need to finish your password with enter and press Ctrl-D. The newline you've entered thus does not appear to become part of the password.
It seems that the first time you run it, you are setting the password. On subsequent runs there is no feedback by gnome-keyring-daemon if the password should be wrong, but obviously your program will not be able to connect later.
I have been using gpg for encryption for a while. Someone suggested that I should use gpg2 instead. When I went to use gpg2, I could do almost nothing; it would complain that access to private keys was required, but I could not seem to get it to use the private keys without gpg-agent running.
It turns out that I intentionally disabled gpg-agent (by using chmod -x /usr/bin/gpg-agent); this caused gpg2 to have very limited functionality and complain to stderr.
The reasons I disabled gpg-agent was following a chain of events.
First, I would SSH into a remote machine and "an agent" would open a popup asking for me to unlock my SSH keys. I did not like this because:
A pop-up on my screen interrupts my workflow
A pop-up on my screen is unlikely to be noticed, so it would appear instead that the connection is stalling instead of querying to unlock an encryption key
The agent appeared to cache my password when I absolutely do not want my password cached (much like sudo's annoying use of password caching, I can disable that in its config); I will always want to enter the passphrase for my encryption keys every time they are used for whatever program is using them.
The pop-up appeared to be owned by a separate process, while I want the specific process using the key to query for the passphrase (even if it's a library that does the actual querying); since I spend most of my activities using command-line tools, that means a GUI application isn't ideal because not everything I do will have access to X11
Automatically starting a separate process in the background removes the concept of "one command, one process", especially if that backgrounded process then lingers after the original command has exited
It turned out to be GNOME's key agent and that I could not uninstall the agent without uninstalling GNOME. So I simply disabled it by chmod -x /usr/bin/gnome-keyring*. I then found that SSH would fall back to another agent so I disabled that too using the same method chmod -x /usr/bin/ssh-agent*
When I started using gpg, I found it had a similar agent, the same one I am asking about. I disabled it immediately for the same reasons; I want software to always ask me for passphrases in order to use a private key. I do not want the passphrase to be cached for any reason whatsoever.
So with gpg2 appearing to require gpg-agent, I would like to ask:
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
Is there a way to use gpg2 without gpg-agent ever running?
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Am I being overly paranoid about the use of passphrase caching? I would be curious to see or be pointed to a discussion of it.
Your concerns are certainly valid IMO. The good news is that there are ways to customize gpg-agent behaviour to suit your needs. For example, use a terminal-based passphrase prompt (PIN entry) instead of a GUI prompt and do not cache passphrases.
Is there a best practice that enables a better way to avoid even accidentally enabling the use of a cached passphrase?
A quick solution, likely not a best practice, is to customize your ~/.gnupg/gpg-agent.conf with the following options:
# Expire cached PINs (passphrases) after zero seconds
default-cache-ttl 0
max-cache-ttl 0
# If you use your GPG keys for SSH auth...
default-cache-ttl-ssh 0
max-cache-ttl-ssh 0
enable-ssh-support
# Use TTY-based PIN entry program (I see pinentry,
# pinentry-curses, pinentry-gnome3, pinentry-tty and
# pinentry-x11 on my system)
pinentry-program /usr/bin/pinentry-tty
I found the following guides on GPG key best practices (more of a general guide around key management, not exactly what you're asking) fairly informative and easy to follow:
https://alexcabal.com/creating-the-perfect-gpg-keypair/
https://riseup.net/en/security/message-security/openpgp/best-practices (somewhat dated, some sections don't work out of the box with latest gpg 2.x versions)
Is there a way to use gpg2 without gpg-agent ever running?
Not with gpg 2.x as far as I am aware of. The man page states the following:
--use-agent
--no-use-agent
This is dummy option. gpg always requires the agent.
I have gpg 2.1.15.
Given that agents are daemons which are expected to be able to answer queries, what prevents another user or service running on the local machine from being able to access my cached or stored credentials?
Good question... By default, gpg-agent uses a socket, so technically any process running as your user could in theory hijack your keys. Don't quote me on this, though. Here's an overview of how the gpg-agent works that will hopefully get you started on finding out the real answer:
https://unix.stackexchange.com/questions/188668/how-does-gpg-agent-work
According to https://wiki.archlinux.org/index.php/GnuPG#Unattended_passphrase in order to provide password directly to gpg - without gpg-agent running - you need to run with following options:
gpg --passphrase-fd 0 --pinentry-mode loopback ...
You need to provide password in console right after running this command. No password prompt will be visible during typing, but you will see typed password.
To hide password while typing you can wrap command in stty:
stty -echo ; gpg ... ; stty echo
I tested this with GnuPG v. 2.2.4: killed gpg-agent, shredded /usr/bin/gpg-agent, then run as described above. Worked well.
I'm writing a shell script to connect to a Linux based remote machine using ssh
After successfully logging in to the remote machine I'm able to execute Linux commands, now the real problem I'm facing is when trying to run the same script for another remote machine which will ask for a local authentication(username and password) upon ssh login to proceed further.
Can someone guide me on how to fill the first line with my username and immediately do a carriage return and perform similar action for password.
I've tried the below code connect.sh
sshpass -p <remote-passwd> ssh root#<remote-ip> 'bash -s' < test.sh
test.sh contain
ls
pwd
If I run connect.sh script it executes perfectly without asking for remote machine password. It also executes ls and pwd
Can I actually replace ls and pwd with my username and password to achieve what I'm trying to do??
Also, Am I looking on something which is not possible?? (I have seen a similar code in VB.NET which is solving my purpose but it is not a robust code and I really don't have any idea on VB scripts)
Update: I'm able to login to remote machine non interactively, but the remote machine environment immediately asks for a local authentication which again requires keyboard interaction, I'm looking for achieving this authentication non interactively
If at all possible, you should configure a public key on the server so you don't have to supply a password. This is more secure and will solve your problem more directly.
You may also want to look into orchestration frameworks, rather than implementing this all yourself. If you're doing small things, Fabric is a good option. If this looks like it'll become something much larger, you should look into something like Ansible, which can also additionally handle system configuration and a million other things, but requires very little setup to get started with.
I am looking to write a script which does following
List item
As I run it, it should ask for sever entry(linux or AIX)
Once it is provided, I should be able to login into it with sudo access
Then it should run command from particular location and display the output.
I have been looking for this entire day on this site, but could not find the satisfactory answer.
Hope to get good response on this.
Thanks
Abhi
There are a couple of ways to do this. As Leo pointed out, you could use Tcl/expect. This tool allows you to emulate a user and interact with programs as if you were at the keyboard. You can provide passwords to login clients and so forth. It's a bit involved and sometimes not so reliable. If you're using ssh to log in, it might be easier depending on your skills just to use your favorite shell script and use pre-exchanged keys for logging in. If you do an ls ~/.ssh in the directory of the system you're logging in from (running the script), you may see a file called id_rsa.pub or similar. If not, you can use ssh-keygen to create one. Then create or edit the file ~/.ssh/authorized_keys on the machine you're logging into. Append the contents of this file (id_rsa.pub) to authorized_keys. This should allow you to log into that user from the other machine without a password (note: This could be a security risk!). Then, you can use the command ssh user#dest -C remote_command to execute your command, obviating the need for expect.
I am using ssh for connecting one of the systems.
I have a perl script in that system which I have to run from my machine. But the commands in remote system runs only when it is in Super user mode (I give su - to become the super user, if I am working directly on the remote system)
But if I have to run the perl script from my system ( I am using OpenSSH for this purpose), in super user mode, how should I do it?
By the way, I have placed the command $sh->system("su -") . But it asks for the password but does not proceed further. I have waited for 5 mins atleast, even then I didnt get any response after I entered the password.
Can anyone say how to deal with this situation?
You could use sudo, and allow your user to become root with no password
Read the entry titled "Can't change working directory" on Net::OpenSSH FAQ to know why it doesn't work.
Then read the other entry, "Running remote commands with sudo", to see how you can solve it.
If you don't want ssh to ask for the password, you can add your client user key in the server .ssh/authorized_keys file of the target user. Using this, ssh won't ask for a password anymore.