As Gilles mentioned in a comment, setting the SHELL variable works as well. It does not have downside of my other answer. Here are the details:
Create .xsessionrc
in your home directory with contents:
SHELL=/usr/bin/fish
Disable custom command in gnome-terminal profile options.
- Log out and in again.
Gnome-terminal should respect the variable and use that custom command. It does for me on Ubuntu 16.04.1 and solves the working directory problem.
Is timestamp_type
in /etc/sudoers
or /etc/sudoers.d/*
set to tty
or ppid
? tty
is the default according to sudo
's man page:
timestamp_type - sudoers
uses per-user time stamp files for
credential caching. The timestamp_type
option can be used to
specify the type of time stamp record used. It has the following
possible values:
global
A single time stamp record is used for all of a user's
login sessions, regardless of the terminal or parent process ID.
An additional record is used to serialize password prompts when
sudo
is used multiple times in a pipeline, but this does not affect
authentication.
ppid
A single time stamp record is used for all processes with
the same parent process ID (usually the shell). Commands run from
the same shell (or other common parent process) will not require a
password for timestamp_timeout
minutes (15 by default). Commands
run via sudo with a different parent process ID, for example from a
shell script, will be authenticated separately.
tty
One time stamp record is used for each terminal, which
means that a user's login sessions are authenticated separately.
If no terminal is present, the behavior is the same as ppid.
Commands run from the same terminal will not require a password for
timestamp_timeout
minutes (15 by default).
The default value is tty
.
This setting is only supported by version 1.8.21 or higher.
If it is set to tty
or ppid
, then that explains why you're being asked for a password every time. Each sudo
command you're running is being executed in a separate gnome-terminal
, and thus a separate tty AND a different parent PID.
Looks like global
is the only setting that will allow what you want.
If that doesn't help, what's your timestamp_timeout
setting? Is it set to 0
? The default should be 15 minutes.
Also check the other timestamp*
settings (timestampdir
, timestampowner
). They could cause this problem if timestampdir
(the default on my debian sid system is /run/sudo/ts) doesn't exist or is not rwX by timestampowner
(default root).
sudo
will log a descriptive error message via syslog and email the administrator (root) if these settings result in an error.
One other option is to edit /etc/sudoers
so that your user can run iftop
without needing to enter your password. e.g.
yourusernamehere ALL= NOPASSWD: /usr/sbin/iftop
See How to run a specific program as root without a password prompt? for more details on this.
Best Answer
In general (ignoring vagrant or other system-specific details) your best bet is to set up authentication with SSH keys, and run
ssh-agent
. Then open the ssh sessions with something like:Or, if you can't use keys, you could rig something up with
sshpass
.Though with the terminal in the middle, this would leave the password set in the terminal's environment. To work around that, you could save the password temporarily in a file:
This still isn't optimal since there's a chance the password hits the disk, so keys would be better.