Là tên người dùng trong trường hợp Unix nhạy cảm?


20

ssh abc@servernamekhác ssh Abc@servernamegì không? Liệu trường hợp của tên người dùng trong Unix?

Người dùng của tôi xác thực qua LDAP.


3
Hầu hết mọi thứ trong Linux đều phân biệt chữ hoa chữ thường. Ý nghĩa: cdkhông giống như CD... Cách duy nhất để thực sự làm cho chúng có nghĩa giống nhau là đặt bí danh trong .bashrctệp của bạn ..
ryekayo

1
Tôi cho rằng điều đó phụ thuộc vào thuộc tính LDAP mà bạn sử dụng cho tên người dùng. Nếu nó không phải là RFC 4519 , thì nó không nhạy cảm, nhưng việc triển khai xác thực vẫn có thể đặt tầm quan trọng của trường hợp lên trên nó. Nó cũng phụ thuộc vào cách xác thực chính xác được thực hiện với LDAP.
Stéphane Chazelas

1
Chỉ cần cố gắng đăng nhập với tên người dùng viết hoa của bạn sẽ trả lời điều này cho bạn chỉ trong vài giây.
Cuộc đua nhẹ nhàng với Monica

Câu trả lời:


14

Giống như tên máy chủ và tên miền, tên người dùng không hoàn toàn là một thứ Unix nhưng thường có thể và thường trải rộng trên nhiều loại hệ điều hành.

Việc chúng có được xem là phân biệt chữ hoa chữ thường hay không phụ thuộc vào tiêu chuẩn được sử dụng để chỉ định chúng.

Tên máy chủ và tên miền rõ ràng không phân biệt chữ hoa chữ thường theo tiêu chuẩn DNS (xem RFC4343 ).

Tên người dùng được lưu trữ trên một phụ trợ cục bộ (/ etc / passwd) hoặc kiểu Unix (NIS) không phân biệt chữ hoa chữ thường theo tiêu chuẩn POSIX .

Tên người dùng được lưu trữ trong LDAP hoặc phụ trợ Active Directory sẽ tuân theo định nghĩa lược đồ thuộc tính được sử dụng uidcnthường lưu trữ tên người dùng có các thuộc tính lược đồ khác nhau, không phân biệt chữ hoa chữ thường nhưng không phân biệt chữ hoa chữ thường. Điều đó có nghĩa là cả hai Abcabccó thể khớp với hoặc không abctùy thuộc vào cấu hình máy chủ ldap.

Do sự không nhất quán này, tôi khuyên bạn chỉ nên sử dụng chữ thường cho cả tên người dùng và tên máy chủ / tên miền và sau đó tránh ssh ABC@SERVERNAME.DOMAIN.COMđiều đó là bất lịch sự.


1
Vì vậy, cách tôi đọc tiêu chuẩn POSIX , vì nó không được chỉ định là phân biệt chữ hoa chữ thường hoặc nhạy cảm toàn bộ bộ ký tự tên tệp di động có sẵn (bao gồm cả chữ hoa và chữ thường), nó sẽ phụ thuộc vào việc triển khai. Đúng không? Điều đó đang được nói, có một quy ước tiêu chuẩn?
Doug R.

1
@DougR. Theo như POSIX, tên người dùng phụ thuộc vào trường hợp. Trường hợp không nhạy cảm sẽ có quy định khác. Độ nhạy trường hợp được ẩn khi đề cập đến bộ ký tự tên tệp di động.
jlliagre

Cảm ơn bạn đã làm rõ. Đó là giả định ban đầu của tôi, nhưng tôi không thể tìm thấy bất cứ điều gì liên quan đến bộ ký tự tên tệp di động đã nêu điều này theo cách này hay cách khác.
Doug R.

5

Có nó là trường hợp nhạy cảm. Tôi không thể cung cấp thông tin kỹ thuật, tôi vừa kiểm tra nó và tự hỏi tại sao bạn không (?)

máy cục bộ của tôi là linux mint như bạn có thể thấy:

# cat /etc/*release
DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.2
DISTRIB_CODENAME=rafaela
DISTRIB_DESCRIPTION="Linux Mint 17.2 Rafaela"
NAME="Ubuntu"
VERSION="14.04.3 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.3 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
cat: /etc/upstream-release: Is a directory

và tôi đã cố gắng kết nối với máy chủ CentOS như thế này:

· Sử dụng (sai) tên người dùng Uppercase:

8D prova # ssh Root@agora-server
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 
Permission denied, please try again.
Root@agora-server's password: 

· Sử dụng tên người dùng chính xác:

8D prova # ssh root@agora-server
root@agora-server's password: 
Last login: Fri Oct  2 01:50:13 2015 from 192.168.0.31
[root@agora-server ~]# 

Là một vấn đề phụ, không nên bảo mật thông tin tốt khi cho phép đăng nhập SSH bằng quyền root như đã thực hiện ở đây (đặc biệt nếu máy phải đối mặt với Internet) Ngày nay, với OpenSSH, điều này thường phải được kích hoạt rõ ràng với tùy chọn PermitRootLogin trong trong sshd_config. Tốt hơn là đăng nhập như một người dùng bình thường và sau đó sử dụng sudo hoặc su để trở thành root chỉ khi cần thiết.
JohnGH

Vâng, đúng vậy, tôi đồng ý, trước tiên vì đó là siêu người dùng và thứ hai là tên người dùng 'root' được kẻ tấn công biết, chỉ phải bắt mật khẩu. Dù sao, đây thực sự chỉ là một Máy ảo chạy cục bộ, không được tiếp xúc với thực tế. Thực hành tốt là sử dụng chứng chỉ rsa ssh để đăng nhập hoặc / cộng với cổng ssh mở chỉ dành cho các yêu cầu đến từ các địa chỉ được phép (quy tắc tường lửa)
lese

3

Trong trường hợp tài khoản cục bộ, tên người dùng là trường hợp nhạy cảm. Khi bạn sử dụng LDAP, nó phụ thuộc. Tôi đã thấy các trường hợp tên người dùng phân biệt chữ hoa chữ thường (trên thiết bị ZFS được kết nối với LDAP) và các trường hợp không quan trọng như ứng dụng khách Solaris LDAP được kết nối với Windows AD.

Những gì bạn nên / có thể thử là xem hệ thống của bạn có đang sử dụng LDAP chính xác hay không bằng cách phát hành getent passwd <username>. Sử dụng lệnh này sẽ cung cấp cho bạn một bản ghi với tên người dùng, thư mục chính và shell cho người dùng được chỉ định. Nếu bạn không thấy bản ghi như vậy, LDAP không được cấu hình đúng.

Có một số nơi bạn nên định cấu hình LDAP và một trong những nơi là:

/etc/nsswitch.conf

passwd: files ldap
group:  files ldap

Bạn cũng cần kiểm tra xem PAM có được cấu hình đúng không và có thể bước quan trọng nhất là xác minh xem máy khách LDAP có được cấu hình và hoạt động không. Hãy thử một công cụ như ldapsearchđể kiểm tra xem LDAP có thể được truy vấn không.

Có một số sách dạy nấu ăn LDAP có sẵn và hầu hết chúng phụ thuộc vào phiên bản Unix và phiên bản LDAP bạn đang sử dụng. Cập nhật câu hỏi của bạn với những chi tiết nếu bạn cần hỗ trợ thêm. Cũng bao gồm thiết lập cấu hình của bạn (tất nhiên không có mật khẩu) có thể giúp các thành viên diễn đàn phân tích vấn đề cụ thể của bạn.


1

Tên người dùng Unix chắc chắn phân biệt chữ hoa chữ thường và hơn thế nữa, sử dụng tên người dùng có ký tự in hoa trên hệ thống Unix có thể tạo ra kết quả không mong muốn, do đó thường nên tránh.

Một số ví dụ:

Nó có thể phá vỡ email cho người dùng. Các tiêu chuẩn cho SMTP cho phép địa chỉ email không phân biệt chữ hoa chữ thường và theo mặc định, MTA nhận tin nhắn sẽ gấp địa chỉ email thành chữ thường để tìm người dùng gửi đến. Nếu tên người dùng có các ký tự viết hoa thì nó sẽ không được giải quyết nếu không có cấu hình đặc biệt ghi đè để phục vụ cho việc này. (điều này ảnh hưởng đến các MTA như sendmail, postfix, v.v. và cả các tác nhân xử lý phân phối như procmail)

Nhiều thiết bị đầu cuối phần cứng ban đầu không phải là trường hợp nhạy cảm. Điều thông thường là họ chỉ sử dụng chữ hoa. Khi đăng nhập vào một số phiên bản của Unix, bắt đầu tên đăng nhập bằng ký tự viết hoa sẽ kích hoạt hệ thống cho rằng bạn đang sử dụng một thiết bị đầu cuối chỉ viết hoa và nó sẽ cho phép gấp chữ hoa - chuyển đổi tất cả chữ hoa đã nhập của bạn thành chữ thường ( sau đó bạn phải thoát các ký tự viết hoa để nói rằng họ là chữ hoa) để giúp bạn nhập tên người dùng mà họ mong đợi sẽ được viết thường. Tôi không tin đây là một thứ trên Linux, nhưng tôi đã thấy nó được trình diễn trên HP-UX.

Vì từ lâu, quy ước chỉ sử dụng các ký tự chữ thường trong tên người dùng, thật hợp lý khi hy vọng rằng các công cụ khác (một số chúng tôi có thể không nghĩ đến) trên hệ thống cũng có thể cho rằng tên người dùng nên viết thường và thực hiện kiểm tra, chuyển đổi, v.v. theo đó, do đó phá vỡ mọi thứ cho người dùng đó.


0

Tên người dùng chắc chắn là trường hợp nhạy cảm. Bạn có thể dễ dàng kiểm tra điều này bằng cách thêm hai người dùng có tên giống nhau:

~ # useradd foobar
~ # useradd fooBar
~ # grep ^foo /etc/passwd
foobar:x:1001:1001::/home/foobar:/bin/sh
fooBar:x:1002:1002::/home/fooBar:/bin/sh

Câu hỏi / câu trả lời này cho thấy cách bù đắp cho ai đó đang cố gắng đăng nhập bằng tên người dùng có trường hợp "sai" theo các máy chủ LDAP. Nhưng lưu ý rằng điều này sẽ chỉ hoạt động nếu tên người dùng được liệt kê dưới dạng chữ thường (hoặc bạn có thể đặt tất cả chữ hoa nếu bạn muốn).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.