Борис Сёмов

Если речь о php и ssh, с помощью https://www.php.net/manual/ru/function.ssh2-exec.php запускать date, и получать результат.

ssh -i /Users/mac-pc/.ssh/id_rsa_second -T [username]@gitlab.com
Либо делать сопоставление в ~/.ssh/config, если не хочется руками каждый раз.

При первом подключении, и ответе yes, ключик сервера, сохраняется на клиенте. При повторном подключении, клиент проверяет, а тот-ли это сервер, или кто-то под него подделывается.
До этого, оригинальность сервера не проверить, о чём и предупреждение.

Я использую под Windows и Linux SecureCRT, а сохранённые сессии синхронизирую через nextcloud. Они там хранятся как отдельные текстовые файлы в структуре каталогов, так что очень удобно их синхронизировать различными способами, в частности, не доверяя внешним сервисам эти данные.
Есть у них клиент и под macos, и под ios. Под android, правда, вроде нет.

Я использую SecureCRT, где есть довольно удобное дерево с сохранёнными сессиями, и авторизацию по зашифрованным с паролем ключам.
Описания не использую, а нужную информацию кратко добавляю в название сервера.

Под Linux использую Remmina, примерно аналогично.

Тем не менее, согласно скрину, проблема происходит при выделении памяти, а MC, вероятнее всего убивает oom. И судя по объёму выделяем ой памяти, MC хочет весь файл буферизировать в памяти до, окончания его приёма, и на это вероятно, памяти не хватает.
Стоит посмотреть dmesg на этот счёт. А также, попробовать консольный sftp клиент.

Зайти через ipkvm.
Или перезагрузиться в режиме восстановления, если такая возможность есть у хостера.

1. .ssh это не файл, это папка в домашней папке пользователя.
2. При генерации ключей создаётся открытый и закрытый ключи. Первый остаётся на месте и используется для авторизации, содержимое второго нужно вставить в файл ~/.ssh/authorized_keys на удалённой машине, отдельной одной строкой. (~ это домашняя папка нужного пользователя, под которым вы потом будете заходить на удалённую машину).

ssh -v -i ~/.ssh/devserver git@<адрес_сервера_разработки>
Так будет куда более понятно, что происходит с авторизацией.
Далее, где лежит приватный ключик у вас локально?
Какие права на authorized_keys? authorized_keys лежит в .ssh/ в домашней папке нужного пользователя?

P.S. Вообще, переносить ключик удобно с помощью ssh-copy-id.

HTTPS (HTTP over SSL) c SSH не связаны, и какие-либо настройки вашего веб сервера не затрагивают SSH и наоборот. Так что это совпадение.

Можно для этих пользователей создать группу, для этой группы описать в конфиге sshd описать блок:
Match Group gitusers
ForceCommand git_restricted
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
PermitTunnel no

Где git_restricted, это скриптик на вашем любимом языке, который проанализирует команду, которую пытался запустить пользователь, и которая будет в переменной окружения SSH_ORIGINAL_COMMAND, и если это одна из нужных команд (git-receive-pack, git-upload-pack, git-upload-archive) будет её выполнять с нужными аргументами.

Если поискать, есть готовые решения. Хотя и написать-то не проблема.