Restricting procfs access
grsec /proc restrictions
|Deletions are marked like this.||Additions are marked like this.|
|Line 32:||Line 32:|
|It is a slight security improvement to restrict access to files such as `/proc/*/cmdline` to limit exposure of the worst type of scripts that accept passwords through `argv`. This can be done under Linux by mounting `procfs` with `hidepid=1` or `2` as an option. See this [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201|commit message]] for details.||It is a slight security improvement to restrict access to `/proc/PID` to processes owned by the user. For instance, hiding `/proc/pid/cmdline` limits exposure of the worst type of scripts that accept passwords through `argv`. This can be done under Linux by mounting `procfs` with `hidepid=1` or `2` as an option. (See this [[https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=0499680a42141d86417a8fbaa8c8db806bea1201|commit message]]). If `hidepid=2` then the `gid=n` mount option specifies a GID to exempt from `/proc` restrictions. Alternatively, a grsecurity-patched kernel with `CONFIG_GRKERNSEC_PROC` enabled hides `/proc/pid` entries in addition to some additonal information. `CONFIG_GRKERNSEC_PROC_GID` specifies grsec's `/proc` restriction exempt GID.|
I want to automate an ssh (or scp, or sftp) connection, but I don't know how to send the password....
First of all, if you actually were to embed your password in a script somewhere, it would be visible to the entire world (or at least, anyone who can read files on your system). This would defeat the entire purpose of having a password on your remote account.
If all you want is for the user to be prompted for a password by ssh, simply make sure your script is executed in a terminal and that your ssh command is executed in the foreground ("normally"). Either ssh or the program specified in the SSH_ASKPASS environment variable will prompt the user for a password if the remote server requires one for authentication.
If you want to bypass the password authentication entirely, then you should use public key authentication instead. Read and understand the man page for ssh-keygen(1), or see SshKeys for a brief overview. This will tell you how to generate a public/private key pair (in either RSA or DSA format), and how to use these keys to authenticate to the remote system without sending a password at all.
Here is a brief summary of the procedure:
test -f ~/.ssh/id_rsa || ssh-keygen -t rsa ssh-copy-id me@remote ssh me@remote hostname # should not prompt for a passWORD, # but your key may have a passPHRASE
If your key has a passphrase on it, and you want to avoid typing it every time, look into ssh-agent(1). It's beyond the scope of this document, though. If your script has to run unattended, then you may need to remove the passphrase from the key. This reduces your security, because then anyone who grabs the key can log in to the remote server as you (it's equivalent to putting a password in a file). However, sometimes this is deemed an acceptable risk.
If you're being prompted for a password even with the public key inserted into the remote authorized_keys file, chances are you have a permissions problem on the remote system. See SshKeys for a discussion of such problems.
If that's not it, then make sure you didn't spell it authorised_keys. SSH uses the US spelling, authorized_keys.
If you really want to store a password in a variable and then pass it to a program, instead of using public keys, first have your head examined. Then, if you still want to use a password, use expect(1) (or the less classic but maybe more bash friendly empty(1)). But don't ask us for help with it.
expect also applies to the telnet or FTP variations of this question. However, anyone who's still running telnetd without a damned good reason needs to be fired and replaced.
Limit access to procfs
It is a slight security improvement to restrict access to /proc/PID to processes owned by the user. For instance, hiding /proc/pid/cmdline limits exposure of the worst type of scripts that accept passwords through argv. This can be done under Linux by mounting procfs with hidepid=1 or 2 as an option. (See this commit message). If hidepid=2 then the gid=n mount option specifies a GID to exempt from /proc restrictions. Alternatively, a grsecurity-patched kernel with CONFIG_GRKERNSEC_PROC enabled hides /proc/pid entries in addition to some additonal information. CONFIG_GRKERNSEC_PROC_GID specifies grsec's /proc restriction exempt GID.