LINUX.ORG.RU

Отваливается после выхода из спящего (suspend) режима примонтированная sshfs-директория

 , , ,


1

2

В более ранней теме всё было решено, всё заработало. Но, к сожалению, после выхода из suspend-режима, директория с sshfs в списке примонтированных устройств отсутствует и каждый раз после выхода из suspend приходится монтировать заново (причём, уже с введением пароля). Что самое интересное: если я выхожу из suspend через 30-40 минут, то sshfs остаётся примонтированным. Но стоит мне зайти в систему из suspend-режима через несколько часов, то всё — sshfs-директория потеряна. Пробовал увеличить до значения «9600» параметр «ServerAliveInterval» в файле /etc/ssh/sshd_config — но это не помогло.

Решение
Экспериментальным путём установил: надо было добавить опцию reconnect к точке монтирования в /etc/fstab. Как обычно, решение простое до невозможности. Странно, почему про reconnect не написано в man fstab? Можно сказать, случайно нашёл решение - увидел в чужом конфиге эту опцию и решил попробовать, благо что смысл перевода подходит под мою ситуацию...
Нашёл про reconnect в man sshfs. Я так понимаю, что в опциях можно указывать любые опции, касающиеся монтируемой файловой системы, указанные в её man?

Вот мои опции, если кому пригодятся: defaults,_netdev,reconnect,user,allow_other

★★★★★

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

Ответ на: комментарий от Desmond_Hume

Да, autofs не пересекается с fstab, там свой механизм. А для sshfs может понадобиться монтирование с ключами.

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

Похоже, где-то с ключами накосячил. Буду разбираться. Один косяк уже нашёл, посмотрю, как это подействует - надо будет опять проверить рабочесть примонтированной точки через несколько часов).

Desmond_Hume ★★★★★
() автор топика

Н-да, ключи не помогли. Стабильное отваливание sshfs происходит... гуглинг не помогает. Люди выходят из ситуации вбиванием одних и тех же команд после suspend.

Desmond_Hume ★★★★★
() автор топика

Но стоит мне зайти в систему из suspend-режима через несколько часов, то всё — sshfs-директория потеряна

А что удивляет-то? TCP сессия считается разорванной. Это не лечится на уровне sshd. Только переустанавливать соединение. А чтобы не вводить пароль повторно и сохранить минимальную секьюрность, рекомендую ключи с паролями и ssh-agent.

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

У меня работает два компа: один мелкий - на атоме (CentOS), а второй обычный - 8-ядерный AMD(Fedora). Мелкий используется для закачки торрентов, eD2K-ссылок и т.п., работает в круглосуточном режиме, т.к. потребляет минимальное кол-во электроэнергии (около 60 Вт). Обычный комп, чтобы не загружать долго (это, конечно, не так долго, как шинда, но..), обычно не выключаю, а просто делаю suspend. Каждый раз, после нескольких часов suspend, когда включаю комп, происходит вся эта оказия с отваливанием sshfs. Пришла мысль, что, возможно, надо смотреть в конфигах на сервере (на мелком компе), а не на клиенте. Воозможно, именно там надо увеличивать параметр ServerAliveInterval, а не на клиентской машине. Если и это не получится, тогда, видимо, придётся отказаться от затеи sshfs в пользу SFTP.

Desmond_Hume ★★★★★
() автор топика
[pushistiq@localhost ~]$ df -hT
df: /mnt/pushistiq-3vi-Downloads: Software caused connection abort
Filesystem     Type      Size  Used Avail Use% Mounted on
devtmpfs       devtmpfs  7.9G     0  7.9G   0% /dev
tmpfs          tmpfs     7.9G  527M  7.3G   7% /dev/shm
tmpfs          tmpfs     7.9G  1.9M  7.9G   1% /run
tmpfs          tmpfs     7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/dm-1      ext4       87G  8.3G   75G  11% /
tmpfs          tmpfs     7.9G  896K  7.9G   1% /tmp
/dev/dm-2      ext4      131G   61G   63G  50% /home
/dev/sda1      ext4      1.4G  176M  1.1G  14% /boot
/dev/sdc1      ext4      2.7T  581G  2.0T  23% /mnt/Container3TB
/dev/sdd1      ext4      1.8T  1.6T  118G  94% /mnt/Container2TB
tmpfs          tmpfs     1.6G   20K  1.6G   1% /run/user/42
tmpfs          tmpfs     1.6G   68K  1.6G   1% /run/user/1000
[pushistiq@localhost ~]$ mount -a
mount: only root can use "--all" option
[pushistiq@localhost ~]$ sudo mount -a
[sudo] password for pushistiq: 
[pushistiq@localhost ~]$ df -hT
Filesystem                                              Type        Size  Used Avail Use% Mounted on
devtmpfs                                                devtmpfs    7.9G     0  7.9G   0% /dev
tmpfs                                                   tmpfs       7.9G  527M  7.3G   7% /dev/shm
tmpfs                                                   tmpfs       7.9G  1.9M  7.9G   1% /run
tmpfs                                                   tmpfs       7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/dm-1                                               ext4         87G  8.3G   75G  11% /
tmpfs                                                   tmpfs       7.9G  896K  7.9G   1% /tmp
/dev/dm-2                                               ext4        131G   61G   63G  50% /home
/dev/sda1                                               ext4        1.4G  176M  1.1G  14% /boot
/dev/sdc1                                               ext4        2.7T  581G  2.0T  23% /mnt/Container3TB
/dev/sdd1                                               ext4        1.8T  1.6T  118G  94% /mnt/Container2TB
tmpfs                                                   tmpfs       1.6G   20K  1.6G   1% /run/user/42
tmpfs                                                   tmpfs       1.6G   64K  1.6G   1% /run/user/1000
pushistiq@192.168.1.41:/var/lib/transmission/Downloads/ fuse.sshfs  455G  186G  246G  44% /mnt/pushistiq-3vi-Downloads
[pushistiq@localhost ~]$ 

Наверное, придётся смириться). На серваке такие вот настройки в /etc/ssh/sshd_config:

#	$OpenBSD: sshd_config,v 1.93 2014/01/10 05:59:19 djm Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

# If you want to change the port on a SELinux system, you have to tell
# SELinux about this change.
# semanage port -a -t ssh_port_t -p tcp #PORTNUMBER
#
#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# 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

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

# Ciphers and keying
#RekeyLimit default none

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

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

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

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

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
#GSSAPIEnablek5users no

# 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'.
# WARNING: 'UsePAM no' is not supported in Red Hat Enterprise Linux and may cause several
# problems.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox		# Default for new installations.
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 9600
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS

# override default of no subsystems
Subsystem	sftp	/usr/libexec/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

Desmond_Hume ★★★★★
() автор топика
Последнее исправление: Desmond_Hume (всего исправлений: 2)

Спасибо арчвики: помогла страничка, на которую она ссылалась - http://linuxmafia.com/~karsten/Linux/FAQs/sshrsakey.html
С ключами разобрался теперь. Посмотрю, что теперь будет. Может ключей не хватало, поэтому всё отваливалось после suspend'a.

Desmond_Hume ★★★★★
() автор топика

Ребята, проблему, кажется, решил. Отпишусь позже, что сделал для этого. Впервые, после 5 часов suspend'a, точка монтирования с sshfs не отвалилась!

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

Спасибо, может пригодиться.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.