For OpenSSH there is BatchMode, which in addition to disabling password prompting, should disable querying for passphrase(s) for keys.
BatchMode
If set to “yes”, passphrase/password querying will be disabled.
This option is useful in scripts and other batch jobs where no
user is present to supply the password. The argument must be
“yes” or “no”. The default is “no”.
Sample usage:
ssh -oBatchMode=yes -l <user> <host> <dostuff>
As you mentioned, the environment variables are removed by sudo
, for security reasons.
But fortunately sudo
is quite configurable: you can tell it precisely which environment variables you want to keep thanks to the env_keep
configuration option in /etc/sudoers
.
For agent forwarding, you need to keep the SSH_AUTH_SOCK
environment variable. To do so, simply edit your /etc/sudoers
configuration file (always using visudo
) and set the env_keep
option to the appropriate users. If you want this option to be set for all users, use the Defaults
line like this:
Defaults env_keep+=SSH_AUTH_SOCK
man sudoers
for more details.
You should now be able to do something like this (provided user1
's public key is present in ~/.ssh/authorized_keys
in user1@serverA
and user2@serverB
, and serverA
's /etc/sudoers
file is setup as indicated above):
user1@mymachine> eval `ssh-agent` # starts ssh-agent
user1@mymachine> ssh-add # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2 # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB # goto user2@serverB w/o typing pwd again...
user2@serverB> # ...because forwarding still works
Best Answer
No.
SSH keys are a public/private key authentication pair. They know nothing of networks1.
Further, the SSH server has no clue what the MAC address of a client is. Its knowledge of the network ends at TCP/IP. There is no reason it would need the MAC address of its clients, and it wouldn't be available for all clients anyway (think about hosts that are not on the local subnet).
1Exception: Host keys are usually associated with the IP address or hostname of the host they belong to, via the
known_hosts
file -- This association isn't strictly necessary for SSH to function, it's just added security to make sure you're connecting to the machine you think you're connecting to.