The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Аутентификация на SSH сервере с использованием ключей (ssh auth pam)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: ssh, auth, pam,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-13 16:35:46 Subject: Аутентификация на SSH сервере с использованием ключей
by Brian Hatch

Перевод: Сгибнев Михаил

OpenSSH кроме паролей поддерживает еще несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и такая экзотика как ключи X509. Но самым популярным является метод Identity/Pubkey.

Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть перехвачены кейлоггером или просто подсмотрены, у нас на диске имеется пара ключей, которые и используются для проверки подлинности. Ваша учетная запись на сервере SSH имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля.

Вот некоторые из положительных моментов этого типа аутентификации:
  • Никто не сможет войти на сервер с Вашей учетной записью, так как им необходимо обладать приватным ключом и кодовой фразой.
  • Администратор сервера может вообще убрать пароль учетной записи, дабы исключить его дискредитацию.
  • Вы можете использовать утилиту ssh-agent и он будет предоставлять аутентификационные данные за Вас.
  • Вы можете устанавливать определенные ограничения, например запрещая перенаправление портов, выполнение определенных программ и т.д.
В этой статье мы рассмотрим методу создания ключей и конфигурирование учетной записи.

Создание Identity/Pubkey

В оригинальной реализации SSHv1 Вы могли создать Identity, которое было парой RSA публичного и приватного ключей. В SSHv2 формат этих ключей был изменен, стали поддерживаться ключи RSA и DSA, и эта аутентификация была переименована в Pubkey. В контексте данной статьи эти обозначения будут использоваться взаимозаменяемо, так как реализуют идентичные функции.

С помощью утилиты ssh-keygen создадим необходимые ключи:
    
    mydesktop$ ssh-keygen -t rsa
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/xahria/.ssh/id_rsa):
      Enter passphrase (empty for no passphrase): (enter passphrase)
      Enter same passphrase again: (enter passphrase)
      Your identification has been saved in /home/xahria/.ssh/id_rsa.
      Your public key has been saved in /home/xahria/.ssh/id_rsa.pub.
      The key fingerprint is:
      2c:3f:a4:be:46:23:47:19:f7:dc:74:9b:69:24:4a:44 xahria@mydesktop
      
      
    mydesktop$ cd $HOME/.ssh
    mydesktop$ ls -l
      -rw-------    1 xahria   hatchclan   883 Jan 21 11:52 id_rsa
      -rw-r--r--    1 xahria   hatchclan   223 Jan 21 11:52 id_rsa.pub
      
    mydesktop$ cat id_rsa
      -----BEGIN RSA PRIVATE KEY-----
      MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5
      gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F
      7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE
      gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW
      Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E
      mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
      /lj06BtBA9iag5+x+caV7qKth1NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
      jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB
      XdBh42izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM
      J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV
      j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH
      9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np
      wtq59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
      -----END RSA PRIVATE KEY-----
      
    mydesktop$ cat id_rsa.pub
        ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
        aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
        2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
        ff5M09PsqNypoLLLZas= xahria@mydesktop
    
    
Обратите внимание, что 'ssh-rsa...xahria@mydesktop' это одна строка, а не несколько.

Как Вы могли убедиться, ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной Вами при создании, НИКОМУ не давайте копаться в этом файле. Второй файл - Ваш публичный ключ, он не содержит никаких тайн и может быть доступен любому встречному-поперечному. В случае утраты он может быть восстановлен из приватного ключа.

Типы ключей SSH

При создании ключей Вы указывали опцию -t rsa. Этим параметром мы указываем тип создаваемых ключей. Также возможно создать ключи rsa1, rsa или dsa. Рассмотрим их отличия:

Тип
Аргумент
Имя по умолчанию
Протокол
Пример заголовка
RSA1
-t rsa1
identity
SSH 1 protocol only
1024 35 118118225938285...
RSA
-t rsa
id_rsa
SSH 2 protocol only
ssh-dss AAAAB3nzaC1kc3M...
DSA
-t dsa
id_dsa
SSH 2 protocol only
ssh-rsa AAAAB3NzaC1yc2E...


Вы можете изменить имя файла с помощью опции -f filename. Если Вы не определили имя файла, то ключи будут записаны в каталог $HOME/.ssh/ с именем, принятым по умолчанию для данного типа ключа.

Разрешение Identity/Pubkey аутентификации на сервере

После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации - Pubkey или Identity, установив следующие настройки в sshd_config:
    
    # Should we allow Identity (SSH version 1) authentication?
    RSAAuthentication yes
      
    # Should we allow Pubkey (SSH version 2) authentication?
    PubkeyAuthentication yes
     
    # Where do we look for authorized public keys?
    # If it doesn't start with a slash, then it is
    # relative to the user's home directory
    AuthorizedKeysFile    .ssh/authorized_keys
    
    
Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys.

Проверьте наличие этих строк в файле конфигурации sshd_config (обычно он находится в каталоге /etc/ssh/), при необходимости добавьте и перезапустите сервис.

Содержимое файла authorized_keys

Файл authorized_keys просто содержит список ключей, по одному в строке. В него мы и пропишем ключ, сгенерированный нами на своей машине.
    
    # Copy the RSA Pubkey to the server using scp.
    # You can use any method you like, including using
    # copy/paste if it's convenient.
    mydesktop$ cd $HOME/.ssh
    mydesktop$ scp id_rsa.pub ssh-server:id_rsa_mydesktop.pub
    xahria@ssh-server's password: (enter password)
      
    # Now let's log in and create the authorized_keys file
    mydesktop$ ssh ssh-server
    xahria@ssh-server's password: (enter password)
     
    # Create the .ssh dir if it doesn't already exist
    ssh-server$ mkdir .ssh
    ssh-server$ chmod 700 .ssh
    ssh-server$ cd .ssh
      
    # Concatenate the RSA Pubkey we just uploaded to
    # the authorized_keys file.  (This will create
    # if it doesn't already exist.)
    ssh-server$ cat ../id_rsa_mydesktop.pub >> authorized_keys
      
    # Let's check out the file
    ssh-server$ cat authorized_keys
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
      aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
      2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
      ff5M09PsqNypoLLLZas= xahria@mydesktop
      
    # Make sure permissions are paranoid
    ssh-server$ chmod 600 authorized_keys
      
    # Excellent, let's log out.
    ssh-server$ exit
    
    
    
    
Прядок действий следующий: копируем публичный ключ RSA на сервер, используя scp или любой другой способ. Создаем файл authorized_keys, если каталога .ssh не существует - создаем. Добавляем публичный ключ RSA в файл authorized_keys. Проверяем, устанавливаем права доступа и выходим.

Пришла пора проверить. что мы наваяли:
    
    mydesktop$ ssh ssh-server
    Enter passphrase for key '/home/xahria/.ssh/id_rsa':
    
    
Ваш SSH клиент будет сначала пробовать пройти аутентификацию по Pubkey/Identity, в случае неудачи - идентификацию по паролю. Он будет искать три имени файлов, заданных по умолчанию, если Вы не указали айл ключа явно и передаст его серверу.

Рассмотрим процесс подключения по разделениям:
  • /usr/bin/ssh соединяется с сервером на порт SSH
  • Клиент и сервер обмениваются ключами, определяется алгорит м шифрования
  • Клиент ищет файлы, по умолчанию испрользуемые Pubkey/Identity
  • Если один из таких файлов был найден, то посылается публичный ключ на сервер и запрашивается аутентификация по этому ключу
  • Сервер проверяет файл authorized_keys пользователя на наличие публичного ключа и посылает клиенту последовательность, зашифрованную открытым ключом . Если приватный ключ защищен кодовым словом, то /usr/bin/ssh просит его ввести для дешифровки приватного ключа.
  • Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей
  • Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix
  • Если клиент не может доказать, что это имеет ключ, то он может предложить другие ключи
  • При отсутствии корректных ключей пользователю будет предложено авторизоваться с помощью авторизации Unix
Все это проходит незаметно для пользователя. Если Вы хотите наблюдать за фазами соединения, то используйте ключ -v:
    
    mydesktop$ ssh ssh-server
    OpenSSH_3.8.1p2, SSH protocols 1.5/2.0, OpenSSL 0x009060cf
    ...
    debug1: identity file /home/xahria/.ssh/identity type 0
    debug1: identity file /home/xahria/.ssh/id_rsa type 1
    debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
    ...
    debug1: SSH2_MSG_SERVICE_ACCEPT received
    debug1: Authentications that can continue: publickey,password,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Offering public key: /home/xahria/.ssh/id_rsa
    debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x601d0 hint 1
    debug1: PEM_read_PrivateKey failed
    debug1: read PEM private key done: type 
    Enter passphrase for key '/home/xahria/.ssh/id_rsa': (Enter wrong passphrase)
     
    debug1: PEM_read_PrivateKey failed
    debug1: Next authentication method: keyboard-interactive
    debug1: Authentications that can continue: publickey,password,keyboard-interactive
    debug1: Next authentication method: password
    xahria@ssh-server's password:  (Enter Unix password)
    
    
Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.

Выбор ключей

Если Вы имеете один ключ для каждого типа, то вы можете использовать стандартные имена файлов и ssh-клиент самостоятельно найдет их и использует, но может так случиться, что Вы используете для аутентификации разные файлы:
    У Вас есть персональный ключ и ключ группы(например, административный), для различных хостов и пользователей. У Вас слишком большой список ключей и сервер отбрасывает вас из-за превышения числа попыток авторизации. Вы хотите использовать специальный ключ, потому как связали с ним специфические особенности - такие как предоставление возможности работать только с командой rsync.
Определить используемый ключ можно с помощью опции -i private_key_file:
    
    mydesktop$ ssh -i ~/.ssh/special_ssh_key  ssh-server
    Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':
    
    
Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа:
    
    mydesktop$ cat ~/.ssh/config
     Host ssh-server
     IdentityFile ~/.ssh/special_ssh_key
      
    mydesktop$ ssh ssh-server
    Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':
    
    
Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.

Безопасность кодовой фразы

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

authorized_keys2

Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу - authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.

Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys.
    
    ssh-server$ cd .ssh
    ssh-server$ ls -l
    -rw-------    1 xahria   hatchclan   883 Jan 21 11:52 authorized_keys
    
    # make a hard link so they are the same file, just different
    # file names.
    ssh-server$ ln authorized_keys authorized_keys2
    
    ssh-server$ ls -l
    -rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys
    -rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys2
    
    
Так мы удовлетворим потребности любой версии OpenSSH.

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, gentoid (?), 15:45, 30/05/2009 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Просто и понятно.
     
  • 1.2, debianid (?), 14:50, 10/01/2010 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Спасибо!
     
  • 1.3, sorron (?), 22:37, 17/05/2010 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    В первой таблице неправильно проставлены два последних примера заголовка
     
  • 1.4, betep (?), 12:55, 10/03/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    nice
     
  • 1.5, антон (??), 13:51, 29/08/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    статья очень полезная
    спасибо
     
  • 1.6, Андрей (??), 18:25, 19/09/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    доступно, просто и понятно
    +1
     
  • 1.7, ЮКЕЙЯЮМДП (?), 14:36, 03/04/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ЛМЕ ОПХЬЕК РЕЙЯР  invalid command                    ВРН ЩРН РЮЙНЕ Х ЙЮЙ ЛМЕ ХЯОПЮБХРЭ ЩРН
     
  • 1.8, ilsid (??), 15:52, 19/09/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Вопрос касательно пункта
    "Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix".

    Каким образом сервер "понимает", что расшифровка удалась? Клиент отсылает ему дешифрованную проверочную строку в открытом виде? Ведь у сервера нет же закрытого ключа для дешифрации.

    Спасибо

     
     
  • 2.13, Вася (??), 22:17, 12/03/2013 [^] [ответить]    [к модератору]  
  • +/
    >Ведь у сервера нет же закрытого
    > ключа для дешифрации.

    Нету. И не надо. У него есть вторая половинка пары ключей - паблик. Эта пара ключей и алгоритм кодирования-декодирования устроены так хитро, что то, что зашифровано приватом, обратно можно расшифровать не приватом, а соответствующим пабликом.

    > Вопрос касательно пункта
    > "Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix".
    > Каким образом сервер "понимает", что расшифровка удалась? Клиент отсылает ему
    > дешифрованную проверочную строку в открытом виде?

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

     
     
  • 3.24, Васькович (ok), 14:17, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    Убить тебя мало! Публичный ключ, потому и публичный, что им можно только шифровать! Дешифровать можно только приватным!
     
     
  • 4.25, Lanched (?), 15:04, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    > Убить тебя мало! Публичный ключ, потому и публичный, что им можно только
    > шифровать! Дешифровать можно только приватным!

    эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то, что зашифровано приватным - можно расшифровать только публичным.

     
     
  • 5.26, Васькович (ok), 17:20, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    > эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то,
    > что зашифровано приватным - можно расшифровать только публичным.

    Прекрасно! Шифруйте приватным, чтобы все прочитали. Смысл сего действа?

     
     
  • 6.27, Васькович (ok), 19:03, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    опровергну сам себя - сертификаты.

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

     
  • 6.28, Lanched (?), 19:04, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    >> эм... вообще-то то, что зашифровано публичным, можно расшифровать только приватным. а то,
    >> что зашифровано приватным - можно расшифровать только публичным.
    > Прекрасно! Шифруйте приватным, чтобы все прочитали. Смысл сего действа?

    1. удостовериться в отправителе.
    2. шифруется обычно своим закрытым ключем и открытым ключем партнера. чтобы никто не послал ему сообщение, представляясь не тем, кем он является.

     
     
  • 7.29, Васькович (ok), 20:56, 23/09/2016 [^] [ответить]    [к модератору]  
  • +/
    вы говорите про подписывание - это отдельный частный случай сертификации. и прошу не путать открытый/закрытый и частный/публичный. частный/публичный относятся строго к стандартной форме обмена: частный дешифрует и держится закрыто, публичный шифрует и дается в свободный доступ между партнерами.
     
  • 1.9, alecs (??), 23:26, 12/12/2012 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей

    Так как всё-таки проверяется подлинность private key ?

     
     
  • 2.12, Вася (??), 21:38, 12/03/2013 [^] [ответить]    [к модератору]  
  • +/
    Общая идея такая:
    твой комп зашифровывает некоторую строку своим приватным ключом (который лежит у тебя на компе и ты его никогда никому не показываешь) и результат отправляет компу, с которым ты пытаешься начать ssh-сессию.
    На том компе уже есть (ты сам его туда положил) твой паблик-ключ.Тот комп берет этот ключ и расшифровывает им твое сообщение. Если расшифровалось - значит, твоя идентичность подтверждена: фокус в том, что пара ключей приват и паблик устроена так, что зашифрованное с помощью приват можно расшифровать с помощью соответствующего паблик - но при этом по паблику восстановить сам приват-кей очень и очень сложно.
    В общем, на том компе - ТОЛЬКО паблик-ключ. И твой приват-ключ он проверяет, не зная вообще, какое конкретное значение у привата: если твоим пабликом расшифровалось то, что ты зашифровал приватом - значит, твой приват и тот паблик, что ты закинул на удаленный комп - это "половинки" одного ключа, то есть, твой приват-ключ верный и с тобой можно начинать ssh
     
  • 1.10, zloyded (?), 08:46, 21/01/2013 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    а если много серверов, как бы так заставить их все разом доверять хосту?
    у меня порядка 300 серверов, сразу их не заставили, а теперь это переодически не обходимо. например для одной короткой операци мне приходтся 300 раз вводить пароль...
     
     
  • 2.11, id_rsa (?), 06:18, 31/01/2013 [^] [ответить]    [к модератору]  
  • +/
    > а если много серверов, как бы так заставить их все разом доверять
    > хосту?
    > у меня порядка 300 серверов, сразу их не заставили, а теперь это
    > переодически необходимо. например, для одной короткой операци мне приходтся 300
    > раз вводить пароль...

    while read server; do cat $HOME/.ssh/id_rsa.pub | ssh username@${server} \'cat >> ~/.ssh/authorized_keys\' ; done < server_list
    как-то так, по-моему. Уж придется последний раз напрячься и ввести 300 паролей, лол.

     
  • 2.14, Lanched (?), 11:16, 24/01/2014 [^] [ответить]    [к модератору]  
  • +/
    ssh-copy-id вам в руки :) один раз ввести пароли.. а если пароль везде одинаковый - то в связке с sshpass. тогда его вообще один раз ввести - и всё.
     
  • 1.15, Дмитрий (??), 13:50, 20/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    у меня при каждом входе по ssh просит  Enter passphrase for key
    можно ли как-то этого избежать, поскольку не удобно постоянно его вводить
     
     
  • 2.16, Lanched (?), 13:53, 20/10/2014 [^] [ответить]    [к модератору]  
  • +/
    > у меня при каждом входе по ssh просит  Enter passphrase for
    > key
    > можно ли как-то этого избежать, поскольку не удобно постоянно его вводить

    можно. пересохрани ключ без использования пасс-фразы.

     
  • 2.22, Pilat (ok), 11:08, 06/04/2016 [^] [ответить]    [к модератору]  
  • +/
    Использовать ssh-add.
    PS
    Я знаю, Что это старое сообщение.
     
  • 2.31, jzyken (?), 14:49, 04/01/2017 [^] [ответить]    [к модератору]  
  • +/
    Чтобы не спрашивал каждый раз, нужно ваш ключ показать ssh агенту:
    ssh-add ~/.ssh/id_rsa
     
  • 1.17, Дмитрий (??), 14:15, 20/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Спасибо за быстрый ответ.
    пересохранить это ssh-keygen -t rsa
    только уже без passphrase?
    Но тогда мне понадобиться переписать ключ и в  authorized_keys на клиенте?
     
  • 1.18, Дмитрий (??), 14:58, 20/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ssh-keygen -p -P old_passphrase -N “” -f .ssh/id_rs
    попытался сделать так, но passphrase все равно просит, только теперь не подходит старая фраза,и  без неё тоже не коннектится  
     
  • 1.19, Дмитрий (??), 15:06, 20/10/2014 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ой, извиняюсь, в предыдущей строке была ошибка с кавычками
    ssh-keygen -p -P old_passphrase -N "" -f .ssh/id_rs
    вот так работает, может кому полезно будет, избавиться от passphrase
     
  • 1.20, Сергей (??), 17:22, 19/08/2015 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    А есть ли сроки у этого ключа? В течении какого промежутка времени он будет действовать?
     
  • 1.21, Андрей (??), 10:38, 24/08/2015 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Вопрос от чайника.Захожу на сайт он мне даёт rsa key.Как я могу им воспользоватса?
     
  • 1.23, имя (?), 23:57, 17/05/2016 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Авторизацию для root настроил. А вот для пользователя bitrix сделал тоже самое, но пароль запрашивается. Может что-то надо иначе делать?
     
  • 1.30, Васькович (ok), 21:01, 23/09/2016 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    В статье криво описан метод подсоединения Вот как он выглядит правильно клиент... весь текст скрыт [показать]
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:





      Закладки на сайте
      Проследить за страницей
    Created 1996-2017 by Maxim Chirkov  
    ДобавитьРекламаВебмастеруГИД  
    Hosting by Ihor