Size: a a a

Russian Fedora Community

2020 December 10

АЛ

Александр Луговой... in Russian Fedora Community
открытые реализации пропиетарного по обычно дерьмо
источник

НР

Никита Разуваев... in Russian Fedora Community
Никита Разуваев
он забыл сказать, что она трафик не шифрует)
нужно ssh-туннель делать
источник

М

Михаил in Russian Fedora Community
Никита Разуваев
он забыл сказать, что она трафик не шифрует)
шифрует лол
источник

НР

Никита Разуваев... in Russian Fedora Community
Михаил
шифрует лол
нет
источник

М

Михаил in Russian Fedora Community
ты дебил
источник

НР

Никита Разуваев... in Russian Fedora Community
@Vascom2 , вмешайся плиз
источник

НР

Никита Разуваев... in Russian Fedora Community
я за бан
источник

l

linxon in Russian Fedora Community
emlen ra
а есть вариант представить участок экрана в качестве устройства-веб камеры?
если только попробовать v4l2loopback
источник

М

Михаил in Russian Fedora Community
By default, RFB is not a secure protocol. While passwords are not sent in plain-text (as in telnet), cracking could prove successful if both the encryption key and encoded password were sniffed from a network. For this reason it is recommended that a password of at least 8 characters be used. On the other hand, there is also an 8-character limit on some versions of VNC; if a password is sent exceeding 8 characters, the excess characters are removed and the truncated string is compared to the password.

UltraVNC supports the use of an open-source encryption plugin which encrypts the entire VNC session including password authentication and data transfer. It also allows authentication to be performed based on NTLM and Active Directory user accounts. However, use of such encryption plugins makes it incompatible with other VNC programs. RealVNC offers high-strength AES encryption as part of its commercial package, along with integration with Active Directory. Workspot released AES encryption patches for VNC. According to TightVNC,[15] TightVNC is not secure as picture data is transmitted without encryption. To circumvent this, it should be tunneled through an SSH connection (see below).

VNC may be tunneled over an SSH or VPN connection which would add an extra security layer with stronger encryption. SSH clients are available for most platforms; SSH tunnels can be created from UNIX clients, Microsoft Windows clients, Macintosh clients (including Mac OS X and System 7 and up) – and many others. There are also freeware applications that create instant VPN tunnels between computers.

An additional security concern for the use of VNC is to check whether the version used requires authorization from the remote computer owner before someone takes control of their device. This will avoid the situation where the owner of the computer accessed realizes there is someone in control of their device without previous notice.
источник

E

E in Russian Fedora Community
так закоснее  :P
источник

М

Михаил in Russian Fedora Community
и где тут закос
источник

НР

Никита Разуваев... in Russian Fedora Community
Михаил
By default, RFB is not a secure protocol. While passwords are not sent in plain-text (as in telnet), cracking could prove successful if both the encryption key and encoded password were sniffed from a network. For this reason it is recommended that a password of at least 8 characters be used. On the other hand, there is also an 8-character limit on some versions of VNC; if a password is sent exceeding 8 characters, the excess characters are removed and the truncated string is compared to the password.

UltraVNC supports the use of an open-source encryption plugin which encrypts the entire VNC session including password authentication and data transfer. It also allows authentication to be performed based on NTLM and Active Directory user accounts. However, use of such encryption plugins makes it incompatible with other VNC programs. RealVNC offers high-strength AES encryption as part of its commercial package, along with integration with Active Directory. Workspot released AES encryption patches for VNC. According to TightVNC,[15] TightVNC is not secure as picture data is transmitted without encryption. To circumvent this, it should be tunneled through an SSH connection (see below).

VNC may be tunneled over an SSH or VPN connection which would add an extra security layer with stronger encryption. SSH clients are available for most platforms; SSH tunnels can be created from UNIX clients, Microsoft Windows clients, Macintosh clients (including Mac OS X and System 7 and up) – and many others. There are also freeware applications that create instant VPN tunnels between computers.

An additional security concern for the use of VNC is to check whether the version used requires authorization from the remote computer owner before someone takes control of their device. This will avoid the situation where the owner of the computer accessed realizes there is someone in control of their device without previous notice.
ну так вот и прочитай что написано.
источник

V

Vascom in Russian Fedora Community
Михаил
ты дебил
В чём дело?
источник

М

Михаил in Russian Fedora Community
Vascom
В чём дело?
он говорит что в vnc нет шифрования
источник

НР

Никита Разуваев... in Russian Fedora Community
Михаил
By default, RFB is not a secure protocol. While passwords are not sent in plain-text (as in telnet), cracking could prove successful if both the encryption key and encoded password were sniffed from a network. For this reason it is recommended that a password of at least 8 characters be used. On the other hand, there is also an 8-character limit on some versions of VNC; if a password is sent exceeding 8 characters, the excess characters are removed and the truncated string is compared to the password.

UltraVNC supports the use of an open-source encryption plugin which encrypts the entire VNC session including password authentication and data transfer. It also allows authentication to be performed based on NTLM and Active Directory user accounts. However, use of such encryption plugins makes it incompatible with other VNC programs. RealVNC offers high-strength AES encryption as part of its commercial package, along with integration with Active Directory. Workspot released AES encryption patches for VNC. According to TightVNC,[15] TightVNC is not secure as picture data is transmitted without encryption. To circumvent this, it should be tunneled through an SSH connection (see below).

VNC may be tunneled over an SSH or VPN connection which would add an extra security layer with stronger encryption. SSH clients are available for most platforms; SSH tunnels can be created from UNIX clients, Microsoft Windows clients, Macintosh clients (including Mac OS X and System 7 and up) – and many others. There are also freeware applications that create instant VPN tunnels between computers.

An additional security concern for the use of VNC is to check whether the version used requires authorization from the remote computer owner before someone takes control of their device. This will avoid the situation where the owner of the computer accessed realizes there is someone in control of their device without previous notice.
каждая конкретная реализация предоставляет ОТДЕЛЬНЫЙ плагин для шифровки. сама технология  RFB - небезопасная
источник

М

Михаил in Russian Fedora Community
я говорил использовать rfb?
источник

V

Vladislav in Russian Fedora Community
Никита Разуваев
зачем косить под нее?))
Кое-где они преуспели в дизайне, но это единственное, в чём они преуспели ;)
источник

М

Михаил in Russian Fedora Community
Vladislav
Кое-где они преуспели в дизайне, но это единственное, в чём они преуспели ;)
нет
источник

М

Михаил in Russian Fedora Community
макось шикарная система
источник

НР

Никита Разуваев... in Russian Fedora Community
Михаил
я говорил использовать rfb?
vnc использует rfb-протокол
источник