2

I'm trying to access a git server from my FreeBSD 11.3 box via root account. git server is secured to only allow access via SSH public key authentication.

When I log into my FreeBSD box, I do that as user. Then sudo to root. When trying to connect to git server, it's prompting for password. When I do not sudo but stay as user and try to connect to git server, SSH pubkey autentication works like charm. Here's the output of ssh -v gitserver

OpenSSH_7.5p1, OpenSSL 1.0.2s-freebsd  28 May 2019
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to gitserver.xxx.tld [192.168.x.y] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: Fssh_key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5 FreeBSD-20170903
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.8
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.8 pat OpenSSH* compat 0x04000000
debug1: Authenticating to gitserver.xxx.tld:22 as '<gituser>'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:<here comes a long key expression>
DNS lookup error: data does not exist
debug1: Host 'gitserver.xxx.tld' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: Fssh_kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Trying private key: /root/.ssh/id_dsa
debug1: Trying private key: /root/.ssh/id_ecdsa
debug1: Trying private key: /root/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:

It seems that ssh-agent is not presenting my key to the remote host...

Any ideas how to fix that? Do I propably use a key cipher that is not allowed to be used by root user (just an idea)?

Regards Olaf

  • 1
    Would it not be better to use git as you non-root user? – Kusalananda Jul 27 at 11:31
2

sudo clears (or resets to default known-safe values) almost all environment variables by default so that they can't be used to exploit the sudo-gained privileges (e.g. by setting PATH or LD_LIBRARY_PATH).

This may be disabled by turning off the env_reset option in /etc/sudoers (VERY strongly NOT RECOMMENDED) or sudo can be configured to preserve other environment variables. For example, in /etc/sudoers:

env_keep += "SSH_AGENT_PID SSH_AUTH_SOCK"

see man sudoers and man sudo for details.


alternatively, if this root account is not shared with other people (e.g. it's your own personal machine), you could generate a key pair for root and then add root's public key to your git server user account.


PS: I've never needed to use env_keep for my ssh agent, but I have used env_keep += "DISPLAY" when I want to run tools like gparted via sudo....i've even used that when ssh -X-ing into a remote machine to run gparted.

0

If you are root on the local machine, by default, ssh will try to use the root user and the root public key to log into the remote machine.

You need to use the user@hostname syntax to specify the user to use to log into the remote machine, and the -i option to specify the keys to use.

For example:

ssh -i ~user/.ssh/id_rsa user@example.com

See ssh(1) for details.

  • this is a good answer, but only works if the user's public and private keys are on the same machine that they are running sudo on. won't work if they, for example, ssh into one machine, run sudo, then want to ssh from there into another....which is one of the main reasons to run an ssh agent. – cas Jul 27 at 10:39
  • Also, the OP will have to re-type their ssh pass phrase....and avoiding that is the other main use for an ssh agent. this is not just laziness, there are situations where you might need to ssh from machine A to machine C via machine B and you don't want to have your passphrase go anywhere near machine B. – cas Jul 27 at 10:48
  • @cas I must admit that I did not understand how ssh-agent fitted into all of this. – Richard Smith Jul 27 at 10:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.