проблемы с несколькими закрытыми ключами

Question

У меня есть несколько пользователей на моем сервере и в качестве отдельной пары открытый / закрытый ключ для каждого.

Проблема в том, что, как только они добавляются в качестве идентификаторов (Mac OS X 10.8.4, если это имеет значение), когда я соединяюсь с учетной записью пользователя, он проходит через все ключи, пытаясь найти правильный. Это не так хорошо работает из-за MaxAuthTries.

Я бы согласился с увеличением моего MaxAuthTries до 100 или около того, но, хотя он принимает это под соответствующим хостом, он не переопределяет оригинал, и я действительно не хочу давать широкой публике 100 попыток аутентификации для моего ssh-сервера ; конфигурация:

MaxAuthTries 2

Match host 1.2.3.4
        MaxAuthTries 100

MaxAuthTries ничего не делает для моего IP; это все еще ограничивает это 2.

Это решение не было бы идеальным, но было бы приемлемым, если бы оно могло быть сделано. При использовании ключа вниз по списку, требуется некоторое время, чтобы проверить их все и найти правильный (особенно, если мое интернет-соединение отстает)... Плюс отправка всех моих ключей, зашифрованных или нет, мне неудобно.

В идеале мне нужно соединиться с правильным файлом ключа и не пытаться попробовать другие. Проблема в том, что большинство моих паролей сохранено в моей цепочке для ключей, поэтому, если я очищаю свои идентификационные данные, я теряю все сохраненные пароли.

Если это невозможно, мне нужен способ изменить MaxAuthTries на большое число для моего IP. Я думал о том, чтобы сделать это с помощью IPTables, но я использую Plesk, и мне нравится иметь возможность использовать интерфейс для управления моим брандмауэром.

Огромное спасибо!!

Answer 1

Я как раз собирался начать вознаграждение за это и понял, что ответ был настолько прост ...

Данные агента SSH не зашифрованы, поэтому их можно получить с помощью сценария оболочки, и я использую bash для выбора правильного имени пользователя, сервера и т.д. В зависимости от заданного домена (который будет vhost на указанном сервере).

Я решил эту проблему, экспортировав открытый ключ из моего агента ssh в файл, принудительно используя только этот ключ, а затем удалив открытый ключ.

Вот мой скрипт bash (надеюсь, он полезен для других!):

#!/bin/bash
remove_public () { # remove the public key after 2 seconds
  sleep 2
  rm -f $HOME/.ssh/public_key $HOME/.ssh/config
}

get_public () { # get the public key from ssh-add
  ssh-add -L | grep "$1" > $HOME/.ssh/public_key
  if [ ! -s "$HOME/.ssh/public_key" ] #identity hasn't yet been loaded
  then
    export KEY="$1" #use the private key it'll be added to the agent for next time assuming agent is configured.
  else
    export KEY="$HOME/.ssh/public_key" #use the public key
    ( remove_public & ) >/dev/null 2>&1
  fi
  chmod 700 "$KEY"
  echo "IdentitiesOnly=yes" > "$HOME/.ssh/config"
  echo "IdentityFile $KEY" >> "$HOME/.ssh/config"
}

ssh_connect () {
  chmod -R 700 $HOME/.ssh
  if [[ -z "$1" || -z "$2" ]]
  then
    echo "Username or server not specified!"
    exit 1;
  else
    get_public "$HOME/.ssh/$2"
    ssh "$2@$1" -i "$HOME/.ssh/$2"
  fi
}

ВНИМАНИЕ, если у вас действительно есть файл ssh_config, это БУДЕТ удалить его. Но важно удалить IdentitiesOnly и IdentityFile; в противном случае ssh будет разорван для соединений, не использующих этот скрипт.

Использование:

ssh_connect "server" "username"

Это урезанная версия сценария оболочки, которую я написал, потому что мои ключи не всегда находятся в одном и том же каталоге (фактически они никогда не сортируются по серверу), я всегда передаю экранную команду серверу и т.д.

Также обратите внимание, что в команде rm, если вы беспокоитесь о безопасности удаленного открытого ключа, вы можете использовать rm -fP вместо rm -f если вы используете Mac OSX, чтобы перезаписать файл 3 раза перед удалением. Я не знаю, какие другие, если таковые имеются, ОС поддерживают это.