Đối với những người trong chúng ta, những người sử dụng SSH, nghĩa là, những người trong chúng ta, những người cần truy cập máy tính hoặc máy chủ từ xa liên tục trong cuộc sống hàng ngày của chúng ta đến mức phát chán với việc nhập mật khẩu, nó sẽ là:
- Nhập một thiết bị đầu cuối: ssh user @ server
- Đợi vài giây
- Máy chủ nơi chúng tôi muốn kết nối sẽ yêu cầu mật khẩu
- Sau khi đặt mật khẩu và nhấn [Enter], chúng tôi sẽ truy cập vào máy chủ từ xa
Và bây giờ câu hỏi của tôi, không phải đơn giản hơn chỉ cần gõ ?:
sshpass -p «PASSWORD» ssh root@servidor
Ví dụ: giả sử người dùng là nguồn gốc, máy chủ là: nhà phát triển.desdelinuxNet. và mật khẩu là xunil ... thì dòng sẽ là:
sshpass -p xunil ssh root@dev.desdelinux.net
Để đạt được điều này, chúng ta chỉ cần cài đặt gói sshpasstrong Debian / Ubuntu hoặc các dẫn xuất sẽ với sudo apt-get cài đặt sshpass Trong khi đó trong ArchLinux hoặc các dẫn xuất sẽ đủ với Sudo pacman -S sshpass
Nếu chúng ta muốn chỉ định cổng (vì SSH không có trên cổng 22) chúng tôi thêm -p «CỔNG» ... nghĩa là, giả sử đó là cổng 9122:
sshpass -p xunil ssh root@dev.desdelinux.net -p 9122
Để đơn giản hóa tất cả điều này hơn nữa chúng ta có thể tạo bí danh, ví dụ: khi thực thi server1, toàn bộ dòng được thực thi để kết nối bằng SSH với server1 (mật khẩu sshpass -p người dùng @ server1) hoặc thứ gì đó tương tự, vì vậy chúng tôi cũng tiết kiệm việc đặt một dòng quá dài 😉
Dù sao, tôi hy vọng điều này có ích cho bạn.
Nhân tiện, một cách khác để tránh phải viết mật khẩu khi chúng tôi truy cập bằng SSH là sử dụng khóa công khai và riêng tư.
Liên quan
Tôi xin lỗi nhưng đây là một lỗi an ninh khủng khiếp !! Bạn có mật khẩu bị kẹt trong tập lệnh, tệp văn bản thuần túy, lịch sử lưu trữ, v.v.
Vì vậy, openssh hỗ trợ xác thực khóa công khai bằng RSA.
Nhờ kiểu thực hành này (được thực hiện bởi các đối tượng tự gọi mình là "quản trị viên") mà máy tính mất an toàn rất nhiều.
Chúc mừng.
Hãy xem nào. Đúng là vấn đề bảo mật nhưng không có nghĩa là “đối tượng” là quản trị viên hay không phải sử dụng phương pháp này. Phương pháp này tồn tại và được hiển thị trong trường hợp nó cần được sử dụng trong môi trường mà vấn đề bảo mật không phải là vấn đề. Trong cửa hàng họ bán cho bạn con dao, bạn quyết định xem mình dùng nó để cắt rau hay giết ai đó.
Tôi hiểu vị trí của bạn, nhưng tôi rất tiếc vì trong một blog nổi tiếng như vậy mà họ lại quảng bá kiểu hành nghề này, nó gần giống như một "lời xin lỗi vì quản trị hệ thống tồi tệ" hehe.
Một cái ôm!!
Tôi vẫn không hiểu vấn đề là gì 🙁
Như chúng ta đã nói về "cách có được bảo mật cao hơn" ở nhiều khía cạnh khác nhau, chúng ta cũng có thể nói về các chủ đề "kém an toàn hơn" khác. Mục tiêu của chúng tôi là cung cấp thông tin, tùy thuộc vào bạn biết phải làm gì với thông tin đó. Ngoài ra, tác giả của bài viết hoang tưởng nhất về bảo mật không thể được, tin tôi đi, khi nói đến Quản trị hệ thống, nó không làm loại điều này.
Xin chào 😉
Đầu tiên, khi tôi nói 'được thực hiện bởi các đối tượng tự xưng là "quản trị viên"', tôi không đề cập đến tác giả của bài báo bất cứ lúc nào, tôi không hiểu tại sao họ lại dễ bị như vậy.
Vấn đề, theo quan điểm của tôi, là công cụ này đi ngược lại tất cả các thông lệ bảo mật tốt. Tôi tin rằng từ cộng đồng GNU / Linux, chúng ta phải giữ cho hệ điều hành quý giá của mình càng an toàn càng tốt. Ý tôi là, tôi không muốn thấy GNU / Linux được chuyển thành Windows (bảo mật khôn ngoan).
Thật không may, có nhiều quản trị viên mới làm quen không biết cách chính xác để thực hiện công việc và cuối cùng sử dụng các công cụ này trên các hệ thống quan trọng.
Tất nhiên bạn có quyền xuất bản những gì bạn muốn, nhưng tôi nhắc lại, tôi rất tiếc vì blog này (một trong những blog quan trọng nhất bằng tiếng Tây Ban Nha) nhường chỗ cho các công cụ đe dọa an ninh.
Chúc mừng!
Và cho Juana với chậu. Chính xác, bởi vì nó là một blog tham khảo, chúng tôi muốn cung cấp tất cả các loại thông tin. Tôi hiểu điều này:
Một người dùng đến và hỏi: Làm cách nào để kết nối với máy chủ thông qua SSH mà không cần mật khẩu?
Họ trả lời anh ta trong bất kỳ diễn đàn nào: Không, đó là một vấn đề bảo mật, không ai làm điều đó.
Ngay cả khi biết, người dùng cũng không cho anh ta biết lý do tại sao đó là vấn đề bảo mật. Xấu, rất tệ, thật tốt khi bạn biết cách làm mọi việc, đó là lý do tại sao trong Desdelinux:
Một người dùng đến và hỏi: Làm cách nào để kết nối với máy chủ thông qua SSH mà không cần mật khẩu?
Chúng tôi viết một bài và nói: Bạn có thể sử dụng phương pháp này, nó hoạt động theo cách này nhưng nó KHÔNG AN TOÀN. An toàn nhất là dùng cái này cái kia.
Điều gì làm bạn suy nghĩ tốt nhất?
Được rồi, tôi tôn trọng tư thế của bạn. Trân trọng!!
SSHPass không thực sự đe dọa an ninh, người đe dọa an ninh trong mọi trường hợp là người dùng lạm dụng nó.
Ví dụ: đây là một ví dụ tuyệt vời rằng SSHPass không chỉ được sử dụng cho những gì tôi nhận xét trong bài đăng, nó có thể được sử dụng cho (ví dụ) bẻ khóa OpenSSH-Server: http://paste.desdelinux.net/4810
Ứng dụng không có gì khác hơn, một ứng dụng, công dụng được trao cho nó là những gì sẽ gây ra lỗi làm ảnh hưởng đến bảo mật hoặc không.
Về vấn đề hồi hộp hay nhạy cảm, có thể đó là cách bạn nói (hoặc cách đọc khiến nó khó hiểu chính xác) nhưng tôi hiểu rằng nhận xét đó là hướng đến tôi, nếu không phải như vậy, tôi xin lỗi.
Tái bút: Chắc chắn sẽ có một số người sẽ tìm thấy kịch bản mà tôi đặt rất thú vị và thậm chí là hài hước LOL!
Ok, tôi rất vui vì chúng tôi đã đạt được thỏa thuận. Chúc mừng !!
Tôi đã bao giờ nói rằng phương pháp này an toàn hơn so với việc sử dụng khóa công khai và riêng tư?
Trong một bài viết khác, tôi đã chia sẻ cách sử dụng chúng [1], bây giờ tôi chỉ đơn giản giải thích một cách khác để đạt được điều tương tự hoặc điều gì đó tương tự.
Mọi người đều sử dụng cái phù hợp với họ nhất, cái mà họ thích. Ở đây tôi chỉ giải thích một cách đơn giản về một trong những cách sử dụng có thể được cấp cho sshpass, một cách khác có thể thông qua tập lệnh Bash để bẻ khóa SSH thông qua việc sử dụng từ điển ... nhưng thôi nào, đây chỉ là một cách sử dụng khác.
Tôi nhắc lại, tôi chỉ chia sẻ kiến thức của tôi liên quan đến GNU / Linux. SSHPass có thể không phải là sự lựa chọn lý tưởng cho mọi trường hợp, nhưng nó có tiện ích, đừng ngần ngại.
BTW, ám chỉ: (được thực hiện bởi các đối tượng tự gọi mình là "quản trị viên") ... heh ... heh ... heh ... Tôi không muốn bình luận, tôi không có gì để chứng minh với bất kỳ ai, chưa kể rằng của bạn. bạn của tôi, bạn không có ý tưởng xa vời nhất về tôi là ai, ít hơn nhiều so với những gì tôi biết 😉
[1] https://blog.desdelinux.net/ssh-sin-password-solo-3-pasos/
Đừng lo lắng, điều xảy ra là trong lĩnh vực của tôi, tôi biết những người làm việc dựa trên Google và khi giải quyết vấn đề, họ sao chép và dán loại thứ này. Sau đó, quản trị viên bảo mật là người “đưa bánh vào bánh” khi phát hiện ra những loại dị thường này. Chúc mừng !!
Thư giãn đi anh bạn, nó không đáng đâu 😉
Chắc chắn, nhưng sau đó mật khẩu được đăng ký trong các lệnh được sử dụng. Vì lý do bảo mật, điều này không nên được thực hiện ...
Đó là những gì tôi đã nghĩ khi đọc bài đăng
Thêm điều này vào .bashrc của chúng tôi sẽ không lưu các lệnh liên quan đến sshpass:
HISTIGNORE='sshpass *'Tôi sẽ thực hiện một bài đăng về cách bỏ qua các lệnh để chúng không bị lưu vào lịch sử bash trong thời gian ngắn :)
Một cách khác để các lệnh không được lưu là luôn đặt khoảng trắng trước lệnh. ^ __ ^
Tôi nghĩ sẽ an toàn hơn khi sử dụng các khóa để kết nối qua SSH mà không cần phải nhập mật khẩu.
Mặt khác, việc tạo một bí danh lệnh đầy đủ để lưu mật khẩu có thể là một vấn đề bảo mật.
Đối với tôi, nếu nó có vẻ là một lỗ hổng trong bảo mật máy tính, nhưng chúng tôi sẽ đảm bảo rằng chúng không được lưu trong lịch sử bash không phải là vấn đề quá lớn mà chúng tôi làm (ngoại trừ bí danh sẽ rất lớn), cũng như elav nói trong cửa hàng bán cho chúng tôi con dao, chúng tôi là người sẽ xem những gì để sử dụng nó
Thú vị, nhưng tốt hơn hãy sử dụng khóa công khai và riêng tư mà bạn đã hiển thị trong một mục nhập khác.
@KZKG
Tôi nghĩ nó thực tế hơn - và an toàn! - sử dụng khóa RSA / ECDSA cùng với chuỗi khóa (SSH agent) để xác thực tự động.
Trong trường hợp của tôi, tôi sử dụng chuỗi khóa SSH cho Keychain, được phát triển bởi những người ở Funtoo, hoạt động rất tốt, sử dụng rất ít tài nguyên và rất an toàn:
http://www.funtoo.org/Keychain
Ví dụ:
j:0 ~ > AliasSearch ssh
# SSH management
alias SSHCOPYIDecdsa='ssh-copy-id -i ~/.ssh/id_ecdsa.pub'
alias SSHCOPYIDrsa='ssh-copy-id -i ~/.ssh/id_rsa.pub'
alias SSHKEYGENecdsa='ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)"'
alias SSHKEYGENrsa='ssh-keygen -t rsa -b 4096 -C "$(whoami)@$(hostname)-$(date -I)"'
Cách sử dụng:
SSHKEYGEN {ecdsa, rsa}
SSHCOPYID {ecdsa, rsa} user @ {server, ip}
# SSH servers
alias SERVER1mosh='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && mosh -p # usr1@server1'
alias SERVER1='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@server1.local'
alias SERVER101='eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa) && ssh -v -p # usr1@[direc. ip].101'
Trường hợp:
-p #: cổng
usr1 @ server1: user @ AVAHI server
usr1@server1.local: user @ AVAHI server (tùy thuộc vào cách máy chủ được định cấu hình trong một số hệ thống, cần thêm hậu tố .local)
usr1 @ [addr. ip] .101: địa chỉ ip cố định.
/ etc / ssh / sshd_config: http://paste.chakra-project.org/4974/
~ / .ssh / config: http://paste.chakra-project.org/4975/
Hệ điều hành: Arch Linux / Chakra
Tôi hy vọng nó phục vụ bạn, lời chào!
Trên thực tế, tôi sử dụng các khóa, không phải SSHPass để truy cập vào máy chủ của mình ... Tôi đã phát hiện ra SSHPass khi tôi cần một cách để thực hiện tập lệnh này: http://paste.desdelinux.net/4810
Nhưng ... tốt, tôi muốn chia sẻ SSHPass với mọi người, nhưng rõ ràng là tôi không thể đặt ở đây một tập lệnh cho phép sử dụng từ điển để cố gắng vi phạm OpenSSH-Server HAHAHA!
«[…] Tôi không thể đặt ở đây một tập lệnh cho phép sử dụng từ điển để cố gắng vi phạm OpenSSH-Server HAHAHA!"
Nhưng tại sao không!!?
Hack & bẻ khóa có phải là một phần của việc học các phương pháp bảo mật tốt [0] không !?
Làm ơn đi đi !!!
[0] Thật không hay khi dùng những từ có nghĩa hoàn toàn trái ngược với nghĩa đen của chúng !? Hack ngôn ngữ học !!! ;-D
Xin chào, tôi gặp lỗi này:
Nó đang thử nghiệm mật khẩu tới 192.168.20.11 trên cổng 22 với người dùng root
cat: con-letter.txt: Không có tệp hoặc thư mục nào như vậy
tệp có chữ cái.txt Tôi tạo chúng?
liên quan
Điều này không được thực hiện, vì mật khẩu được lưu trữ trong bash_history dưới dạng văn bản thuần túy, ngoài ra nó có thể được tìm ra theo cách khác. Vì vậy, ssh không yêu cầu bạn nhập mật khẩu, cách chính xác là với "khóa công khai và riêng tư".
Tôi sử dụng RSA để kết nối với máy chủ của mình từ xa, thậm chí vì vậy tôi nghĩ rằng để kết nối với một số máy tính mà chúng tôi không yêu cầu bảo mật mạnh mẽ như vậy là một công cụ tốt, cảm ơn bạn đã mách nước!
Chiuuuu
Và tại sao tốt hơn là không công bố mật khẩu của tôi để nó có sẵn cho bất kỳ ai?
Xuất sắc mà tốt !!!!!! và bằng tiếng Tây Ban Nha.
Bài viết xuất sắc, như mọi khi mọi người phàn nàn thay vì cảm ơn, mặc dù phương pháp này không an toàn, nó phụ thuộc vào vị trí và cách bạn sử dụng nó, cảm ơn bạn rất nhiều 🙂