I am currently stuck on an error in git using gitlab 14.10.4. I can ssh -T git@IP_ADDRESS but not ssh -T git@FQDN . I am using the same key, same machine where I can connect to git via ssh on ip address. What am I missing?
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:VX3JDVrZYNtFpFUhiQR11IYdRCotA/yl/H0DodwKqRY agent
debug2: pubkey_prepare: done
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:VX3JDVrZYNtFpFUhiQR11IYdRCotA/yl/H0DodwKqRY agent
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
git@fqdn: Permission denied (publickey,password).
my setup would be gitlab server is proxied on a separate web server. but I already tried attaching the ip address directly on the gitlab server and still encounter the same error where I can connect to the gitlab server via ssh on ip address, while not via FQDN.
I might be wrong, but when you have IdentityFile ~/.ssh/id_rsa in your ssh config, I think ssh only tries that (and those that are provided by an agent if you have one running). That suggests that it uses a different key when you ssh to the ip, try to show us the output like the above, but from an attempt to connect to the ip.
But as ~/.ssh/id_rsa is (part of) the default, the explanation must lie in the “part of”, as an ssh to the ip wouldn’t try other keys (unless you didn’t show us your entire .ssh/config, there might be default settings).
here is the entire ssh_config
*# This is the ssh client system-wide configuration file. See*
*# ssh_config(5) for more information. This file provides defaults for*
*# users, and the values can be changed in per-user configuration files*
*# or on the command line.*
*# Configuration data is parsed as follows:*
*# 1. command line options*
*# 2. user-specific file*
*# 3. system-wide file*
*# Any configuration value is only changed the first time it is set.*
*# Thus, host-specific definitions should be at the beginning of the*
*# configuration file, and defaults at the end.*
*# Site-wide defaults for some commonly used options. For a comprehensive*
*# list of available options, their meanings and defaults, please see the*
*# ssh_config(5) man page.*
Host *
*# ForwardAgent no*
*# ForwardX11 no*
*# ForwardX11Trusted yes*
*# PasswordAuthentication yes*
*# HostbasedAuthentication no*
*# GSSAPIAuthentication no*
*# GSSAPIDelegateCredentials no*
*# GSSAPIKeyExchange no*
*# GSSAPITrustDNS no*
*# BatchMode no*
*# CheckHostIP yes*
*# AddressFamily any*
*# ConnectTimeout 0*
*# StrictHostKeyChecking ask*
*# IdentityFile ~/.ssh/id_rsa*
*# IdentityFile ~/.ssh/id_dsa*
*# IdentityFile ~/.ssh/id_ecdsa*
*# IdentityFile ~/.ssh/id_ed25519*
*# Port 22*
*# Protocol 2*
*# Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc*
*# MACs hmac-md5,hmac-sha1,umac-64@openssh.com*
*# EscapeChar ~*
*# Tunnel no*
*# TunnelDevice any:any*
*# PermitLocalCommand no*
*# VisualHostKey no*
*# ProxyCommand ssh -q -W %h:%p gateway.example.com*
*# RekeyLimit 1G 1h*
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
Host FQDN
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa
CheckHostIP yes
(How come you knew how to format output in the original post, but didn’t do it this time?)
I think something is fishy around keys, from the recent output:
debug1: Offering public key: RSA SHA256:GCOmXVN7463SEXRS+2MqMPh9l6X/+2J1ZvGHCm/6aiQ /home/user/.ssh/id_rsa
but that is not the fingerprint in the error message you quoted in the first post:
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:VX3JDVrZYNtFpFUhiQR11IYdRCotA/yl/H0DodwKqRY agent
Could it be that you’re using two different users, but just change both usernames to “user” before posting here? Other than that, I can’t imagine what you can have done to make that happen.
Correct. Apache can be used as a reverse HTTP proxy but does not understand nor forward other protocols such as SSH. Another option would be to use a reverse SSH tunnel to connect to the FQDN server, and then to the gitlab_server host, something like this in a terminal: ssh git@FQDN -L 9000:gitlab_server:22 and on a second terminal, ssh git@127.0.0.1 -p 9000 (untested).
Not sure if that works reliably with Git, though; never done that. I’d suggest using HTTPS as a Git protocol here or providing the GitLab Server with its own dedicated VM and removing the other VHosts that could influence performance.