как залогинится по ssh по паролю(без ключа т.е.) но автоматически.

Phoenix

ssh host cmd< pass.txt
судя по ману -f для этого сделана, но всё равно пароль спрашивает
своя: freebsd
логинюсь на linux.
хотя это неважно, как я понимаю

AlexV769

судя по ману -f для этого сделана

-f Requests ssh to go to background just before command execution.

Перловая реализация ssh такое умеет. Остальные не без причины говорят "you do not want it".

Chupa

спамеры libssh юзают )

AlexV769

p5-Net-SSH2 в свое время выдавала неадекватный ответ от сервера - почему-то резало содержание.

vall

ssh -T и скрипт чтоб пароль скормить только после приглашения, можно на chat сделать.

Phoenix

а можно поподробнее.. что за скрипт и как его скормить?

vall

а хз, openssh очень старается чтоб это не работало, похоже она переоткрывает stdin в момент аутентификации и ничего ей не скормишь.

AlexV769

а чем обосновано нежелание пользоваться авторизацией по ключу?

Phoenix

на сервере отключена.
по крайней мере не захотело авторизовывать меня ключом

AlexV769

проверь что это действительно отключено - конфиг в /etc/ssh/ лежит.

banderon

А вдруг прав на чтение нет?

Irina22

кто ж меня туда пустит-то?
да я просто ключик добавил. он всё равно пароль спрашивал.
можешь в линкуксе как-то по особенному делается.
до этого момента - всё работало с ключами

AlexV769

а вдруг это проверить можно?

artimon

ssh -v host.com
ищем строчку
debug1: Authentications that can continue: publickey,keyboard-interactive

Irina22

странно.
debug1: Connection established.
debug1: identity file /home/igor/.ssh/keys/iigor.hosting.ua type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5p1 FreeBSD-20061110
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'hu.bookvalley.ru' is known and matches the DSA host key.
debug1: Found key in /home/igor/.ssh/known_hosts:27
debug1: ssh_dss_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/igor/.ssh/keys/iigor.hosting.ua
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
где посмотреть, что я делаю неправильно?
ключ генерился на серваке, после его публичную часть добавил в .ssh/authorized_keys

AlexV769

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

Irina22

0700 для .ssh
0644 для authorized_keys
0600 для ключиков
всё правильно вроде

AlexV769

перевод строки после твоего ключа в authorized_keys есть?

Irina22

угу

Irina22

я вот думаю, что просто изменено имя authorized_keys в конфиге

AlexV769

ну значит ключ скопировал неправильно

AlexV769

это опять же можно проверить

Irina22

сделал ещё раз - тоже самое.

artimon

Права на хомовую на удалённом сервере какие? SSH отказывается от авторизации по ключу, если в твою хомовую может писать кто-то кроме тебя.
Ну и cat /etc/ssh/sshd_config посмотри

BondarAndrey

0644 для authorized_keys

вроде тоже должен быть 600 (у меня, по крайней мере так работает)

kruzer25

С 644 должно работать по крайней мере не хуже, счем с 600

serega1604

это исходя из каких соображений ты делаешь такой вывод?
например один фтп-сервер при запуске в директории, на которую права 777 выдает примерно такое сообщение - "ААА, хозяин, нас предали, всякие other могут писать в мою корневую директорию. я работать в таком состоянии отказываюсь." и не запускается.

Irina22

это ж публичные ключи.
от того, что их прочитают, никому хуже не станет.
там же чтение, а не запись

Fragaria

Часто этот файл называют authorized_keys2, так как есть 2 версии протокола SSH

family

ключ генерился на серваке, после его публичную часть добавил в .ssh/authorized_keys

Хм, когда я аутентификацию по ключам настраивал, ключ генерировался как раз на клиенте и отправлялся(открытая часть) на сервер в ~/.ssh/id_rsa.pub и добавлялся в ~/.ssh/authorized_keys(опять же на сервере).

krishtaf

~/.ssh/authorized_keys

этого достаточно

Chupa

> Часто этот файл называют authorized_keys2
уже давно не называют, разве что у динозавров такое осталось
http://marc.info/?l=openssh-unix-dev&m=100508718416162&a...

Fragaria

Ну тем не менее я бы попробовал всё равно.

Marinavo_0507

А чё, логи сервера читать, прежде чем пробовать, разве не модно?

Irina22

нет доступа к логам)