LINUX.ORG.RU

ssh ключи и PuTTY

 , ,


0

2

Здравствуйте.Тема обглоданная но всё же,помогите пожалуйста. 1.Создаю на стороне сервера(по ssh-логин пароль)ключи

ssh-keygen -t rsa
Enter file in which to save the key (/root/.ssh/id_rsa):(оставляю пустым)
(первое что что то не так если при запросе и ввода пароля
Enter passphrase (empty for no passphrase):12345
ключи не создаются?)
ну это ладно.(потом разберемся - главное разобраться с соединением)

ключи создались в каталоге (/root/.ssh/)если на все запросы оставлять пустыми.

Далее создаю файл cat id_rsa.pub >> authorized_keys потом в /etc/ssh/ssd_config

ssd_config

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 3976
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
##AuthorizedKeysFile     %h/.ssh/authorized_keys
AuthorizedKeysFile      /root/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

Разкомментирую строки и указываю путь до ключей

RSAAuthentication yes
PubkeyAuthentication yes
##AuthorizedKeysFile     %h/.ssh/authorized_keys
AuthorizedKeysFile      /root/.ssh/authorized_keys
Далее по ftp скачиваю ключи.

В puttygen(конвертация ->импортировать ключ)выбираю скаченный с сервера ключ(не публичный,без расширения который). сохраняю его(даю свое имя ну например ere,сохраняется он как ere.ppk) ну дальше в putty в ssh выбираю этот ключ и все,соединения нет.Высвечивается

Using username "kalli".
Server refused our key
kalli@xxx.xxx.xxx.xxx's password:



Последнее исправление: beastie (всего исправлений: 1)

Нечитаемо. Можно кратко и по делу, простыни оставив вовне (pastebin, gist в помощь)?

Andrey_Utkin ★★
()

Прочитал пару строк в начале и пару в конце.
1) Тема действительно обглоданная, хватит ее глодать.
2) Таскать ключи через FTP неудобно, копипастить через буфер обмена проще.

thesis ★★★★★
()

Генерить пару ключей надо на клиенте, а не на сервере, например средствами той же путти, а потом уже публичный ключ писать в authorized keys на сервере.

PolarFox ★★★★★
()
Ответ на: комментарий от PolarFox

ssd_config - а там все верно указанно?

kolli
() автор топика
Ответ на: комментарий от ArcFi

папку .ssh делала одновременно в разных директориях устанавливала права доступа 700 на файл 600.нет соединения.

kolli
() автор топика
Ответ на: комментарий от kolli

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

ArcFi
()
Ответ на: комментарий от ArcFi

Но с позиции безопасности так будет правильнее.

М? Я зашел в консоль, сгенерил ключ, потом скопипастил его себе на комп, и затёр на сервере.

Mr_Alone ★★★★★
()
Ответ на: комментарий от Mr_Alone

Удалённые файлы с некоторой вероятностью поддаются восстановлению.
Кроме того, если сервер уже скомпрометирован, то при появлении новых файлов в интересных каталогах, копия данных файлов может автоматически отправляться злоумышленнику.
А ведь этот ключ может использоваться более чем на одном сервере...

ArcFi
()
Ответ на: комментарий от ArcFi

Удалённые файлы с некоторой вероятностью поддаются восстановлению.

Кем? Обычным пользователем? А если взять диск достать из сервера? Да-да. Вот сгенерил ты ключ на своём сервере, а рядом уже стоит чувак, и вынимает диск из твоего сервера.

Кроме того, если сервер уже скомпрометирован

Кому нафиг впёрся очередной ssh ключ на уже взломанном сервере?

А ведь этот ключ может использоваться более чем на одном сервере...

Чувак только-что сгенерил ключ, а он оказывается уже используется на многих серверах.


Не нужно высасывать из пальца невероятные сценарии. Иначе можно придумать, что на клиентском компьютере, а он обязятельно вендовый, давно висит вирус, который все ssh ключи шлёт напрямую в Пентагон.

Mr_Alone ★★★★★
()
Ответ на: комментарий от Mr_Alone

Согласен.
Гораздо выше вероятность того, что приватный ключ просто забудут удалить с сервера.

ArcFi
()

Не надо ничего менять в конфигах, они по умолчанию работают правильно. Скорее всего

AuthorizedKeysFile /root/.ssh/authorized_keys

эта строка всё портит.

Также надо проверить владельца и права доступа на сервере. Должно быть так (для пользователя me):

$ ls -la /home/me/.ssh
total 12
drwx------  2 me  me  512 Oct 25 18:28 .
drwxr-xr-x  7 me  me  512 Nov 13 15:30 ..
-rw-------  1 me  me  405 Nov 21 22:05 authorized_keys

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

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Не надо ничего менять в конфигах, они по умолчанию работают правильно. Скорее всего

AuthorizedKeysFile /root/.ssh/authorized_keys

эта строка всё портит.

+1, параметру AuthorizedKeysFile следует вернуть его исходное значение и перезапустить сервис.

ArcFi
()
Ответ на: комментарий от kolli

ВСЕ СРАБОТАЛО.Спасибо всем.Создала на сервере два ключа.публичный переименовала.Личный на на пути конвертировала. <AuthorizedKeysFile следует вернуть его исходное значение и перезапустить сервис> Вернула.

kolli
() автор топика
Ответ на: комментарий от kolli

Единственный форум где помогли реально.вот мой дневничок.Мож кому поможет.

на сервере создаём папку в /root/.ssh потом ключи ssh-keygen -t rsa

ключ с .pub переименовываем в mc нажимаем f5 в authorized_keys.В каталоге /home/kolli/(создаем .ssh(папка .ssн парава 700 хозяин kolli группа root) и копируем туда authorized_keys(в нутри ключ должен быть в одну строчку,должна быть одна строчка).Другой ключ копируем в путти в программе puttygen.exe — конвертация --- выбераем файл и конвертируем(получается файл xx.ppk).дальше сохраняем.Потом самой пути в ssh(ауэдификация) загружаем и в настойках соединения(сеанс) указываем порт и домен и на соединение.

незабыть внести изменение в ssd_config.

RSAAuthentication yes

PubkeyAuthentication yes

AuthorizedKeysFile %h/.ssh/authorized_keys

Запрещаем вход по паролю в файле ssd_config разкомментируем и изменим на — no

PasswordAuthentication no

вводим в терминале su и пароль супер пользователя пото mc.если мс до супер пользователя то получаются корябки

kolli
() автор топика

судя по последней строчке, можно было проще сделать

ssh-copy-id
Avial ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.